New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix release merge issues MBS-10188 and MBS-10279 #1148
Conversation
378bdd0
to
a14818e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Localization of future ModBot edit notes is probably worth an improvement ticket.
For the ModBot bit, I'd suggest also adding a separate ticket to convert previous notes to the new format with a SQL script at some point (a lot should be trivial to improve). |
Prior to this commit, there were three different subroutines for calculating recording merges for $EDIT_RELEASE_MERGE edits. As you might expect, these did not share a common implementation. 1. Data::Release::determine_recording_merges: This was used for detecting "bad" recording merges where the artists differed (see root/release/merge.tt). 2. Edit::Utils::calculate_recording_merges: This was added for storing `recording_merges` in the edit data, for display and historical purposes (see 0e41a26), but still not for deciding what would actually get merged. (And after 0e41a26, $EDIT_RELEASE_MERGE edits did not display any recording merges that would actually happen, only those that were predicted to happen when the edit was opened. Thus, the edit might say "All recordings for these releases are already merged" while open, yet that may have been false.) 3. Data::Medium::merge: This is what implemented the actual merge logic. It received a couple fixes over the years in dae5b54 and c1992b2, both of which could cause the result of the edit to disagree with the display (assuming, at a minimum, the tracklist didn't change in the meantime). These three methods have been unified into Data::Release::determine_recording_merges, but the implementation is largely based on the previous Data::Medium::merge method. The reasoning for its being moved to Data::Release (and Data::Medium::merge being removed) is that (1) a recording could appear multiple times on the release, which needs to be factored into the merge calculation, and (2) it doesn't make sense to merge two arbitrary mediums outside the context of a release merge. This commit also fixes the display issue mentioned in point 2 above. We now display the recording merges that will actually happen when the edit is applied, not those that were (incorrectly) calculated when the edit was opened. Additionally, when the edit is accepted, we update the edit_data table to save the applied recording merge info for historical display purposes.
It's already invoked in Edit::Release::Merge::do_merge. And it confesses a possibly-incorrect error message here.
ModBot's notes are currently always stored and displayed in English. With this commit, a note can be stored in the database in a special format: localize:{"message": "...", "args": {...}} where "message" is a message in our gettext catalog, and "args" are any substitution arguments needed. When loading a note from ModBot, we check if it's in this format before displaying it, and parse it to form a localized string using those parameters. This syntax can only be used in notes left by ModBot (a regular user could not).
Return (success, reason) instead of adding _cannot_merge_reason to the hash that was passed in.
While we would always skip recordings that had multiple merge targets, we did this silently without informing the user (allowing the release merge to go through). This makes it an explicit error (causing the release merge to fail) with a user-visible explanation. The user will be required to fix the tracklists before proceeding with the merge.
We weren't wrapping _merge_submit here for anything that wasn't validation, so we can use _validate_merge instead. Returning 0 from _validate_merge prevents _merge_submit from running altogether.
This makes more sense to me, and also means we don't have to call determine_recording_merges twice. Explanatory comments have been added.
We previously addressed this in c1992b2 by silently ignoring such situations (but allowing the release merge to go through). It turns out that the fix there only works for some types of merge cycles, but not all. It also seems unsafe to allow releases with potentially misordered recordings to be merged at all, so this is now a hard error. Note: I added ModBot to t/sql/initial.sql, since a lot of tests use them. ModBot has an editor id of 4, which conflicts with unrelated tests. I had to fix the editor ids in those tests to not conflict with ModBot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems good to me now :) I haven't tested it locally though since I guess I would have to come up with a bunch of complicated conditions to reproduce it, but since you added tests, I expect they're good!
ba8d5ea
to
ed369f3
Compare
Tweaked the message, since it might also show if the medium counts are the same, but a medium position is missing from the target. |
The current `medium_track_counts` error is shown in cases where the target release is missing a medium position present on one of the source releases, which doesn't make sense. I've created a separate error message for this case. Thanks to @reosarevok for the wording.
https://tickets.metabrainz.org/browse/MBS-10188
https://tickets.metabrainz.org/browse/MBS-10279