MusicBrainz Server update, 2024-10-21

As mentioned in the banner of MusicBrainz website for a week already, images for events and releases are currently unavailable due to the Internet Archive (IA) recovering from a DDoS attack. See the IA’s Mastodon page for follow-up. Both the Cover Art Archive and the Event Art Archive were available from the Internet Archive which is doing its best to restore services safely, that will take as many days as necessary. Meanwhile, today’s server update temporarily disables editing images, until our access to the Internet Archive is fully restored. It also brings some updates behind the scenes. Last but not least, it also features a few improvements and bugfixes, mainly contributed by volunteers without whom this would not have the same significance!

A new release of MusicBrainz Docker is also available that matches this update of MusicBrainz Server. See the release notes for update instructions.

Thanks to derat, Divyansh Gupta, and Serial-ATA for having contributed to the code. Thanks to Dan and HibiscusKazeneko for having reported bugs and suggested improvements. Thanks to Arainuki, Aris_8585, blit, Echelon666, salo.rock, Vaclovas Intas, and wileyfoxyx for updating the translations. And thanks to all others who tested the beta version!

The git tag is v-2024-10-21.0.

Continue reading “MusicBrainz Server update, 2024-10-21”

MusicBrainz Server update, 2024-07-11

Keep enjoying your summer with this refreshing release dessert, mainly fixing bugs and making improvements after the large two-course meal that was the database schema change and the addition of event art.

A new release of MusicBrainz Docker is also available that matches this update of MusicBrainz Server. See the release notes for update instructions.

Thanks to chaban, Piotr, Relaxo5, salo.rock, and yindesu for having reported bugs and suggested improvements. Thanks to ApeKattQuest/MonkeyPython, Aszazin, Early6431, Felipe Silva, Lunae_XD, salo.rock, Vaclovas Intas, wileyfoxyx, WorldPioneerXXX, yyb987, and yyoung for updating the translations. And thanks to all others who tested the beta version!

The git tag is v-2024-07-11.0.

Continue reading “MusicBrainz Server update, 2024-07-11”

MusicBrainz Server update, 2024-06-24

You may notice some exciting changes to event pages today. We’ll be making a proper announcement of the “EAA” in a separate post soon. 🙂

We have several other bug fixes and improvements as part of today’s release, plus a new report about video recordings for editors.

In the back-end, we’re making better use of our PostgreSQL standby, which should help with scalability. Development-wise, we’ve done a lot of JavaScript refactoring and upgrading of dependencies.

A new release of MusicBrainz Docker is also available that matches this update of MusicBrainz Server. See the release notes for update instructions.

Thanks to JadedBlueEyes for aligning release titles in release groups. Thanks to Aerozol, atj, chaban, Chiark, Mathias Kunter, RVMWSN, sammyrayy, UltimateRiff, VBZPPlNQyJ, wileyfoxyx, yindesu and zas for having reported bugs and suggested improvements. Thanks to ApeKattQuest, BestSteve, BlueCamille, Felipe Silva, kellnerd, salo.rock, Vaclovas Intas, wileyfoxyx, yyb987, and Zetas70, for updating the translations. And thanks to all others who tested the beta version!

The git tag is v-2024-06-24.

Continue reading “MusicBrainz Server update, 2024-06-24”

MusicBrainz schema change release, 2022-05-16 (with upgrade instructions)

We’re happy to announce the release of our May 2022 schema change today! Thanks to all who were patient during today’s downtime as we released everything to our production servers, and thanks to ikerm2003, mfmeulenbelt rinmon and salo.rock for updating the translations.

This is once again a fairly minor release as far as schema changes go, but please do report any issues that you come across, especially related to the propagation of ratings and tags.

Continue reading “MusicBrainz schema change release, 2022-05-16 (with upgrade instructions)”

MusicBrainz schema change release, 2021-05-17 (with upgrade instructions)

We’re happy to announce the release of our May 2021 schema change today! Thanks to all who were patient during today’s downtime as we released everything to our production servers.

This is a fairly minor release as far as schema changes go, but please do report any issues that you come across, especially related to the display of recordings, releases and release groups on artist and release group pages.

New, user-facing changes with this release are limited to the new ability to merge collections (MBS-10208) and the addition of ratings for places (MBS-11451). Additionally, MBS-11463 adds a new view that is used to fix a couple small requests related to disc IDs (MBS-11268) and release length calculation (MBS-11349). Two other changes – adding a first-release-date field to recordings (MBS-1424) and support for PKCE in OAuth (MBS-11097) are more or less end-user affecting but were already released on the main MusicBrainz servers a while ago. All other changes are under the hood only.

We ran into a few complications while working on this schema change update, so we decided to postpone two changes to our October schema change to ensure only stuff we are more confident on is released. Those are MBS-11457, which involves dropping the ordering_attribute column for series and would have had no direct effect on user experience, and MBS-11456, which would have added MBIDs for artist credits.

A few of the released new features and improvements — namely the first-release-date field for recordings, and the performance improvements to artist pages — make use of new materialized tables. These tables aren’t dumped, nor are they replicated, since they’re derived entirely from primary table data. Rather, we’ve added a new script to build them (admin/BuildMaterializedTables, included in the upgrade instructions below), and triggers to keep them up-to-date once they’re built. These triggers are created on replicated servers, too. If you use the web interface or web service at all, just note the extra step of running BuildMaterializedTables after upgrade.sh below!

A new release of MusicBrainz Docker is also available that solves an issue for live indexing and matches this update of MusicBrainz Server. See the release notes for update instructions.

Now, on to the instructions.

Schema Change Upgrade Instructions

Note: Importing the latest data dump is always a valid alternative to running ./upgrade.sh on an existing database, if you’d prefer to also get new data in one go. Just follow the relevant instructions in INSTALL.md. The git tag is v-2021-05-19-hotfixes. The rest of the instructions here assume an in-place upgrade.

  1. Make sure DB_SCHEMA_SEQUENCE is set to 25 in lib/DBDefs.pm.
  2. If you’re using the live data feed (your REPLICATION_TYPE is set to RT_SLAVE), ensure you’ve replicated up to the most recent replication packet available with the old schema. If you’re not sure, run ./admin/replication/LoadReplicationChanges and see what it tells you; if you’re ready to upgrade, it should say “This replication packet matches schema sequence #26, but the database is currently at #25.”
  3. Take down the web server running MusicBrainz, if you’re running a web server.
  4. Turn off cron jobs if you’re automatically updating the database via cron jobs.
  5. If you’re using the live search indexing, stop it and, assuming sir is under the same directory as musicbrainz-server, run cd ../sir && python2.7 -m sir triggers && cd - && ./admin/psql < ../sir/sql/DropTriggers.sql && ./admin/psql < ../sir/sql/DropFunctions.sql
  6. Switch to the new code with git fetch origin followed by git checkout v-2021-05-19-hotfixes.
  7. Install newer dependencies Perl 5.30 or later and NodeJS 16 according to install prerequisites.
  8. Run cpanm --installdeps --notest . (note the dot at the end) to ensure your perl-based dependencies are up to date.
  9. Run ./upgrade.sh (it may take a while to vacuum at the end).
  10. Set DB_SCHEMA_SEQUENCE to 26 in lib/DBDefs.pm as instructed by the output of ./upgrade.sh.
  11. If you’re using the web interface or web service, run ./admin/BuildMaterializedTables --database=MAINTENANCE all to build new materialized tables. These will take several additional gigabytes of spaces and be kept up-to-date automatically via triggers. For more information, see INSTALL.md.
  12. If you’re using the live search indexing, assuming sir is under the same directory as musicbrainz-server, run cd ../sir && git fetch origin && git checkout v2.1.0 && python2.7 -m sir triggers && cd - && ./admin/psql < ../sir/sql/CreateFunctions.sql && ./admin/psql < ../sir/sql/CreateTriggers.sql and rebuild indexes (by running cd ../sir && python2.7 -m sir reindex && cd -) then start it in watch mode (with cd ../sir && git fetch origin && git checkout v2.1.0 && python2.7 -m sir amqp_watch)
  13. Turn cron jobs back on, if applicable.
  14. Restart the MusicBrainz web server, if applicable. It’s also recommended you restart Redis. If you’re accessing your MusicBrainz server in a web browser, run ./script/compile_resources.sh.

Here’s the list of resolved tickets:

New Feature

  • [MBS-10208] – Allow merging collections
  • [MBS-11451] – Support ratings for places
  • [MBS-11463] – Add view to easily access medium track lengths
  • [MBS-11652] – Add support for artist series (hotfixed)

Improvement

  • [MBS-10962] – Speed up listing artist’s releases
  • [MBS-11268] – Show “Set track durations” on release/discids page
  • [MBS-11460] – Add materialized tables to fetch release groups by artist or track artist

Database Schema Change Task

  • [MBS-10647] – Add [no label] to b_del_label_special trigger for labels
  • [MBS-11453] – Change entity0_cardinality, entity1_cardinality to SMALLINT
  • [MBS-11459] – Create the edit_data_type_info function on mirrors
  • [MBS-11464] – Drop table statistics.log_statistic
  • [MBS-11466] – Change language.frequency and script.frequency to SMALLINT

Previously Released Changes

  • [MBS-1424] – Add a ‘First release date’ field to recordings
  • [MBS-10821] – Edit changing medium tracklist and format is stuck
  • [MBS-11097] – Support PKCE (Proof Key for Code Exchange) by OAuth clients
  • [MBS-11431] – Speed up /ws/js/check_duplicates

Leaked email address incident: 2020-11-23

We’re saddened to write that we’ve let some of our users down by accidentally leaking their email addresses and birth dates via a bug in the web pages of musicbrainz.org. This caused some users to receive unwanted spam emails.

However, we would like to emphasize that no passwords, passwords hashes or any other bits of private user information other than email addresses and birth dates were leaked.

If you have never added or edited an annotation on MusicBrainz, then your email address and birth date were never leaked and you can ignore this — your data has not leaked.

What happened

About two weeks ago a MusicBrainz editor contacted us to say that their email address that was in use only at MusicBrainz had received spam. The user changed the email address to a very distinct email address in order to rule out a spammer guessing the updated email address. But it happened again, and the user received email to the unguessable email address. 

At this point we began an audit of the MusicBrainz server codebase in an attempt to find out where the leak was, patch it as soon as possible, and discover who was affected by it.

What we found

On 2019-04-26 we released a new version of the MusicBrainz server and in this version we added email addresses to the list of editor data we pass to our server to build MusicBrainz pages. The goal of this was to display them in admin-facing pages to, ironically, be able to fight spammers who were using MusicBrainz as a spamming tool. We also added the editor’s birth date, to be able to congratulate them on their birthday. Neither of these cases should have ever been a problem, since the private data should only be used on pages built and sent from our own server (where the data cannot be seen by anyone else), and any editor info sent to the users’ browser goes through a “sanitizing” process eliminating all this private information.

After some digging, we discovered that due to a bug we had overlooked in the code that stripped this data, the addresses and dates had started being sent to the browser whenever an entity page with an annotation was requested. The email address and birth date of the last person to have edited an annotation in MusicBrainz (any annotations, attached to any of our entities) was leaked on the page for the entities in question. This data was contained in a massive block of JSON data in the page source and was never shown on the web page for humans to see, which is why this issue went undetected for so long.

Who was affected

We looked at all editors who wrote any annotations that were displayed between the date the problematic code was released and the date the bug was fixed. This can mean either the annotation was written during this time period, or it was written before that but (being the latest version of the annotation for the entity) it was still displayed during this time period. This gave us a total of 17,644 editors whose data was at some point visible from the JSON block in at least one entity’s source code. We sadly do not have a way to know for sure how many of the affected were actually ever found and stored by spammers, since we attempt to block botnets as much as possible. As such, we simply have no way of knowing who was really affected by this leak — only who might have been.

What we’ve done

Once we detected the issue on November 22, we immediately put out a hotfix to all production (and beta) servers plugging the leak. The hotfix acted to sanitize the editor data by removing email addresses and birth dates from the JSON. We also deployed two additional changes that should help prevent similar issues from occurring, by avoiding sending sensitive editor data to our template renderer altogether. See all changes from the git tag v-2020-11-22-hotfix.

We are planning to improve our testing infrastructure to detect exposure of editor data — this will become a routine part of our continuous integration process. We are also going to ensure that any pull request dealing with editor data goes through a strict testing checklist.

How did spammers get these email addresses?

You might be wondering how such an obscure leak in a web page can end up in spammers finding and using your email — you’re not alone. 

Our sites are under near constant traffic from seemingly random internet bots fetching thousands of our pages in a day, with no apparent goal. All of our metadata is available for download, so why would someone download pages from us at random?

Well, we now know — web pages can contain a whole host of random data that shouldn’t be there. Email addresses, birth dates and such are just the starting point — there have been websites that have leaked credit card numbers and even login passwords, possibly compromising the integrity of user accounts.

In this case it appears that a botnet kept downloading pages from musicbrainz.org and driving the load on our servers up. We’ve been trying to block botnets ever since they’ve come into existence, but this is a laborious task that is never complete.

It appears that spammers used the botnet to scour the internet for private data such as emails to then send out lovely spam emails to all compromised users.

Summary

We would like to wholeheartedly apologize for this data leak. We take data privacy seriously and we aim to have high standards about privacy and data security. We find ourselves frustrated by the endless data leaks that happen on the Internet on a seemingly continuous basis and work hard to avoid committing these mistakes in our domain. However, we’re also human and we do make mistakes periodically. As explained above, we’re working to improve our systems and processes in order to prevent this from happening again.

We hope that you accept our most sincere apologies for this leak.

Robert Kaye, Michael Wiencek, Nicolás Tamargo and Yvan Rivierre

PostgreSQL 12 Upgrade Instructions for MusicBrainz Server

Thanks to everyone for your patience during our downtime today. As promised, here are steps to follow to upgrade your own PG instance to v12. (Confused? See the previous blog post on this subject.)

If you’re already running v12, there are still some instructions you must follow!

For MusicBrainz Docker

If you’re running the new MusicBrainz Docker setup, an upgrade script exists for you to use. See the release notes for specific – hopefully brief – instructions.

For a Manual Setup (INSTALL.md Based)

If you aren’t using Docker but rather set up musicbrainz-server by hand following INSTALL.md, see the steps below.

Know that as an alternative, you can always import new data dumps from scratch (again following the steps in INSTALL.md) into a new PG 12 cluster. Just make sure you’re on the v-2020-05-18-postgres12 tag of musicbrainz-server while doing so.

If on the other hand you don’t mind getting your hands a bit dirty, you can use the quicker method below. Like INSTALL.md, this assumes you’re using Ubuntu/Debian and their postgresql-common cluster management tools.

If you’re already running v12, you should still follow these steps; however, you can skip the ones involving apt-get, pg_dropcluster, and pg_upgradecluster. The main steps you need to follow in this case are running the 20200518-pg12-before-upgrade.sql and 20200518-pg12-after-upgrade.sql scripts in that order.

On distros other than Debian/Ubuntu where the postgresql-common tools aren’t available, you’ll have to manage with initdb and pg_upgrade on your own.

  1. First take down the web server running MusicBrainz (stop plackup) to prevent database access.
  2. Turn off any cron jobs updating or accessing the database (e.g. for the live data feed/replication packets).
  3. Switch to the latest musicbrainz-server code with:
    git fetch origin && \
    git checkout v-2020-05-18-postgres12
  4. With PG 9.5 (or whatever version you’re using) still running, run the following “pre-upgrade” script:
    psql -U postgres -d musicbrainz_db \
    -f admin/sql/updates/20200518-pg12-before-upgrade.sql

    This assumes that “postgres” is the name of your PG superuser, and “musicbrainz_db” is the name of your database. If you see a few messages about things not existing, that’s normal.

  5. Install packages for PostgreSQL 12. On Ubuntu/Debian you can obtain them from the PGDG apt repo.
    apt-get update && \
    apt-get install postgresql-12 postgresql-server-dev-12

    If you’re installing postgresql-12 for the first time, this will automatically create a new cluster at /var/lib/postgresql/12/main. Remove that empty cluster. Don’t run this if you already had v12 installed and have data there!

    pg_dropcluster --stop 12 main
    If you did already have v12 installed with musicbrainz_db running there, leave the cluster alone and skip the next step involving pg_upgradecluster.

    In the unlikely event that you already have a v12 cluster, but also have musicbrainz_db running in a separate, older cluster, these instructions won’t work for you. We recommend importing fresh data dumps into the v12 cluster and dropping the old one.

  6. Upgrade the old cluster. This assumes it’s version 9.5; if you’re using version 10 or 11, make sure to replace 9.5 below with 10 or 11. If you have other databases in your old cluster besides musicbrainz_db, be aware that this will upgrade all of them to PG 12.
     pg_upgradecluster -v 12 9.5 main
  7. If all goes well, the new cluster should be up and running. (You can drop the old one if you like; the output of the pg_upgradecluster command will tell you how.) Now run the following “post-upgrade” script on the database:
    psql -U postgres -d musicbrainz_db -f \
    admin/sql/updates/20200518-pg12-after-upgrade.sql
    This may take a bit, as it has to recreate some indexes.
  8. The upgrade is complete. You can turn cron jobs back on, if applicable.
  9. Restart the MusicBrainz web server / plackup, if applicable. If you’re accessing the server in a web browser, the usual release upgrade steps apply, like running ./script/compile_resources.sh again.

If you run into any trouble following the above, please let us know and we’ll try to help resolve your issue as soon as possible!

MusicBrainz schema change release, 2019-05-13 (with upgrade instructions)

We’re happy to announce the release of our May 2019 schema change today! Thanks to all who were patient during today’s downtime as we released everything to our production servers.

This is a fairly minor release as far as schema changes go, but please do report any issues that you come across, especially any related to genres and collections.

Visible changes with this release are limited to an indication if a specific artist credit is being edited (MBS-5387). Work on some of the changes to collections and genres is quite advanced, and we’re hoping to release some of the new features onto beta already in a week or so from now, while others might take a while longer.

Now, on to the instructions.

Schema Change Upgrade Instructions

Note: Importing the latest data dump is always a valid alternative to running ./upgrade.sh on an existing database, if you’d prefer to also get new data in one go. Just follow the relevant instructions in INSTALL.md. The git tag is v-2019-05-13-schema-change. The rest of the instructions here assume an in-place upgrade.

  1. Make sure DB_SCHEMA_SEQUENCE is set to 24 in lib/DBDefs.pm.
  2. If you’re using the live data feed (your REPLICATION_TYPE is set to RT_SLAVE), ensure you’ve replicated up to the most recent replication packet available with the old schema. If you’re not sure, run ./admin/replication/LoadReplicationChanges and see what it tells you; if you’re ready to upgrade, it should say “This replication packet matches schema sequence #25, but the database is currently at #24.”
  3. Take down the web server running MusicBrainz, if you’re running a web server.
  4. Turn off cron jobs if you’re automatically updating the database via cron jobs.
  5. Switch to the new code with git fetch origin followed by git checkout v-2019-05-13-schema-change.
  6. Install newer dependencies Yarn and NodeJS 8 or later according to install prerequisites.
  7. Run cpanm --installdeps --notest . (note the dot at the end) to ensure your perl-based dependencies are up to date.
  8. Run ./upgrade.sh (it may take a while to vacuum at the end).
  9. Set DB_SCHEMA_SEQUENCE to 25 in lib/DBDefs.pm as instructed by the output of ./upgrade.sh.
  10. Turn cron jobs back on, if applicable.
  11. Restart the MusicBrainz web server, if applicable. It’s also recommended you restart redis. If you’re accessing your MusicBrainz server in a web browser, run ./script/compile_resources.sh.

Here’s the list of resolved tickets:

Bug

  • [MBS-5387] – ACs being edited aren’t marked as having pending edits on the aliases tab
  • [MBS-9365] – event_meta_fk_id was never created as part of any upgrade script
  • [MBS-9462] – Standalone databases created before schema 21 are missing some l_event_url triggers
  • [MBS-10146] – Regression: ISE on Remove DiscID page
  • [MBS-10149] – Swap track titles with artist credits fails to update both fields properly
  • [MBS-10150] – Regression: The link to the release group reviews in the release page is broken

Improvement

  • [MBS-9664] – Add database constraints to disallow loop relationship
  • [MBS-10044] – Add place area to place lists

Database Schema Change Task

  • [MBS-10052] – Add new schema for the event art archive
  • [MBS-10173] – Create a genre table in the DB and populate it with existing genres
  • [MBS-10174] – Create an addition timestamp in the DB for new collection items
  • [MBS-10175] – Create a position integer in the DB for collection items
  • [MBS-10176] – Create a comment text field in the DB for collection items
  • [MBS-10177] – Create an editor_collection_collaborator table for collaborative collections
  • [MBS-10178] – Create a genre_alias table
  • [MBS-10181] – Create filesize for cover art and each thumb in the DB

React Conversion Task

  • [MBS-9925] – Convert collection pages to React
  • [MBS-10179] – Convert all entity list components to React

MusicBrainz Server update, 2019-04-26

We finally have a new release! Some large conversions of the MusicBrainz website templates to React happened during the past three months, leading to a long delay between releases – sorry about that! This release also fixes several bugs and adds some small improvements.

Thanks to Cyna, Ge0rg3, and spellew for their contributed code, mostly written during GCI. Also, thanks to alpinetux, amCap1712, chirlu, culinko, cyberskull, derobert, Griomo, hibiscuskazeneko, Jeluang, jessew, kepstin, Kid Devine, ListMyCDs.com, Lotheric, mfmeulenbelt, rafwuk, RavenWorks, samj1912, yindesu, yurim, and everyone who tested beta version, reported issues, or updated website translations.

The git tag is v-2019-04-26.

Bug

  • [MBS-6895] – Cannot inc=tags when browsing releases
  • [MBS-8634] – Privileged user accounts page still mentions the style council
  • [MBS-9013] – Removing specific ordering of relationships doesn’t create an edit
  • [MBS-9276] – Transient test failure in Edit::Instrument::Merge
  • [MBS-9297] – “Set track lengths” from Disc ID with no change should not be allowed
  • [MBS-9309] – Mediums fail to merge when two recording positions are swapped
  • [MBS-9400] – Tags are missing from artist nodes in /ws/2/release JSON requests
  • [MBS-9413] – Older “Remove relationship” edits can’t be loaded
  • [MBS-9669] – UI language menu not available in Spanish and Greek
  • [MBS-9845] – country.null stats not being collected
  • [MBS-9893] – Batch voting check boxes disappeared
  • [MBS-9899] – Recording and recording artist tags/genres missing in JSON WS
  • [MBS-9943] – Autocomplete.js is pretty much untranslatable
  • [MBS-9975] – Clicking the “A-a” button (guess sort name) to add a release alias sort name does not work.
  • [MBS-9983] – Non-group artists statistics does not include characters
  • [MBS-9985] – “Last updated on Invalid date” on release sidebar
  • [MBS-9986] – RG types not translated on sidebar
  • [MBS-9991] – Relationship names are not translatable
  • [MBS-9993] – MusicBrainz server should allow CORS requests to /oauth/token
  • [MBS-9995] – Space missing in autoeditor election text
  • [MBS-10009] – Some sidebar types are not translated
  • [MBS-10021] – ArtistRoles is not translatable
  • [MBS-10027] – t::MusicBrainz::Server::Controller::Admin::EditBanner fails randomly
  • [MBS-10031] – Tooltip says ‘null’ for artist names in ‘writer’ column of ‘work’ search results
  • [MBS-10033] – Missing space after Wikipedia blurb
  • [MBS-10045] – Regression: External links to Anison Generation in the sidebar appends https
  • [MBS-10075] – Release with no mediums disappears from release collection when sorting on format/no. of tracks
  • [MBS-10081] – Invalid last updated date on search result pages
  • [MBS-10084] – Unable to add CDBaby URL containing “ï”
  • [MBS-10085] – Long URL fails to wrap on release page in Chrome
  • [MBS-10088] – Example search for relationships breaks with cardinality
  • [MBS-10090] – Loading a doc page containing %3F loads full wikipage html
  • [MBS-10099] – Lyrics URL relationship uses the wrong link phrase on work edit page

Improvement

  • [MBS-6574] – Recursive area tabs
  • [MBS-7463] – Add redirect from /tag to /tags
  • [MBS-8782] – Show artist name on “Edit Note” tab of “Edit Release” page
  • [MBS-8922] – User reporting: Remove “Reveal my email address” option (or default it to on)
  • [MBS-9340] – Don’t allow more languages if [No lyrics] is selected
  • [MBS-9656] – [Change release quality] → [Change data quality]
  • [MBS-9935] – Indicate what to do with annotation reports
  • [MBS-9936] – Move from CJS style to ES6 (imports, exports)
  • [MBS-9988] – On /tags page, allow to go back to not showing downvoted tags
  • [MBS-9989] – Add new “Not applicable” gender option to stats
  • [MBS-9990] – Make formatUserDate error rather than return wrong date if given object
  • [MBS-9998] – Improve cleanup of Facebook URLs
  • [MBS-10008] – Generalize and localize CPDL link’s title in the sidebar
  • [MBS-10010] – Simplify sidebar_name methods for URLs
  • [MBS-10029] – When viewing edits by editor X, include editor X in the page title
  • [MBS-10032] – Detect and clean iTunes “author” URLs for artists
  • [MBS-10063] – “No linguistic content” → “[No lyrics]” in work edits display
  • [MBS-10074] – Display – on release search results for format/tracks if no medium exists
  • [MBS-10094] – Right-justify barcode on release group page
  • [MBS-10101] – Allow SecondHandSongs performance URLs for Recordings
  • [MBS-10102] – Use the containing country area of artists and labels for country statistics
  • [MBS-10103] – Update Bandsintown URL cleanup to strip languages

New Feature

  • [MBS-10011] – Congratulate/thank users on their birthdays
  • [MBS-10022] – Event tab for areas

React conversion task

  • [MBS-9632] – Convert statistics to React
  • [MBS-9699] – Convert the user account pages to React
  • [MBS-9904] – Convert the list of privileged users to React
  • [MBS-9909] – Convert report templates to React
  • [MBS-9926] – Convert entity subscribers pages to React
  • [MBS-10005] – Convert “Details” and ”Tags” tabs, for each entity, to React
  • [MBS-10007] – Convert “Add annotation” edit display to React
  • [MBS-10014] – Convert “Add area” edit display to React
  • [MBS-10015] – Convert “Add artist” edit display to React
  • [MBS-10016] – Convert “Add event” edit display to React
  • [MBS-10017] – Convert artist/cannot_split.tt to React
  • [MBS-10018] – Convert artist/special_purpose.tt to React
  • [MBS-10019] – Convert the artist and place event pages to React
  • [MBS-10026] – Convert the Labels page for Area to React
  • [MBS-10042] – Convert “Aliases” tab, for each entity, to React
  • [MBS-10046] – Convert /admin/banner/edit to React
  • [MBS-10049] – Convert user/report to React
  • [MBS-10086] – Convert attributes admin lists to React
  • [MBS-10091] – Convert root/components/relationships.tt to React

Other task

  • [MBS-8360] – Show BookBrainz relationships in the sidebar
  • [MBS-9082] – Standardize SecondHandSongs URLs
  • [MBS-9932] – Remove or update “Releases with superfluous data tracks” report
  • [MBS-9999] – Allow setting custom redirect URI while registering applications to be installed
  • [MBS-10035] – Add text to the “Report editor” page asking for links
  • [MBS-10036] – Add ccMixter.org to other database whitelist
  • [MBS-10037] – Send editor reports to MB user admin mailing list
  • [MBS-10080] – Relabel “MusicBrainz Blog” link as “MetaBrainz Blog” on MusicBrainz frontpage

Schema change release, 2017-05-15 (including upgrade instructions)

We’re happy to announce the release of our May 2017 schema change today! Thanks to all who were patient during today’s downtime as we released everything to our production servers.

This is a fairly minor release as far as schema changes go, but please do report any issues that you come across.

Currently, the only visible change for editors is the ability to add multiple lyrics languages to works. We’ve also modified the schema to support dynamic attributes for entities other than works, but the UI for that won’t be complete for another release or two.

Now, on to the instructions.

Schema Change Upgrade Instructions

Note: Importing the latest data dump is always a valid alternative to running ./upgrade.sh on an existing database, if you’d prefer to also get new data in one go. Just follow the relevant instructions in INSTALL.md. The rest of the instructions here assume an in-place upgrade.

  1. Make sure DB_SCHEMA_SEQUENCE is set to 23 in lib/DBDefs.pm.
  2. If you’re using the live data feed (your REPLICATION_TYPE is set to RT_SLAVE), ensure you’ve replicated up to the most recent replication packet available with the old schema. If you’re not sure, run ./admin/replication/LoadReplicationChanges and see what it tells you; if you’re ready to upgrade, it should say “This replication packet matches schema sequence #24, but the database is currently at #23.”
  3. Take down the web server running MusicBrainz, if you’re running a web server.
  4. Turn off cron jobs if you’re automatically updating the database via cron jobs.
  5. Switch to the new code with git fetch origin followed by git checkout v-2017-05-15-schema-change.
  6. Run cpanm --installdeps --notest . (note the dot at the end) to ensure your perl-based dependencies are up to date.
  7. Downgrade DBD::Pg by running cpanm TURNSTEP/DBD-Pg-3.5.3.tar.gz (version 3.6.0 breaks things currently).
  8. Run ./upgrade.sh (it may take a while to vacuum at the end).
  9. Set DB_SCHEMA_SEQUENCE to 24 in lib/DBDefs.pm as instructed by the output of ./upgrade.sh.
  10. Turn cron jobs back on, if applicable.
  11. Restart the MusicBrainz web server, if applicable. It’s also recommended you restart redis. If you’re accessing your MusicBrainz server in a web browser, run npm install followed by ./script/compile_resources.sh.

For those curious, here’s the list of resolved tickets (excluding MBS-8393):

Bug

New Feature

  • [MBS-9271] – Prevent usernames from being reused

Task

  • [MBS-9273] – Fix the a_ins_edit_note function in older setups to not populate edit_note_recipient for own notes
  • [MBS-9274] – Fix the edit_note_idx_post_time_edit index in older setups to handle NULL post_time

Improvement

  • [MBS-5452] – Support multiple lyric language values for works