Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Updated: Comment #0
Problem/Motivation
Following the D7 d.o upgrade, the "Issues" entity reference field has the following issues:
- The field is now single-value instead of multi-value, meaning that existing data for change notifications tied to more than one issue has been lost. An example can be found in https://drupal.org/node/2116417 which should previously have referenced about 10 different issues.
- The issue node ID is not included in the autocomplete pattern, which means that issues have to be autocompleted based on title. This is different from how the issue reference fields on issue nodes works, and different from the D6 version of the form.
Proposed resolution
- Include the issue node ID in the entity reference autocomplete pattern.
- Make the issues field a multi-value field.
- Restore the missing data to the field.
Comments
Comment #1
eliza411 CreditAttribution: eliza411 commentedLooks like there are two tags out there. D.o UX is in wider use atm, so I'm adding it.
Comment #3
yoroy CreditAttribution: yoroy commentedAnd the UX catch-all tag :)
Comment #4
xjmJust discovered that it's not just hard to use... it's now single-value instead of multivalue. @jthorson confirmed this for me. This means that we've lost all the data where multiple issues referenced a single change notification. We need to make the field multivalue and restore this data. This is a critical bug that significantly impacts the developer documentation for Drupal 8.
Comment #5
xjmGot a bit smashy on the keyboard there.
Comment #6
xjmComment #7
mcrittenden CreditAttribution: mcrittenden commentedIn that case, removing the Usability tag.
Comment #8
webchickThe data seems to still be in the field_data_field_issues table, from what I can tell. There are numerous rows there with multiple deltas, e.g. https://drupal.org/node/1400186 looks like at least 15 issues reference it. It might be that this is as simple as changing the field configuration to be multivalue instead of single value so that this gets picked up, but I wouldn't want to try that on production. :P~
We need someone to request a d.o development environment and do some testing.
Also, it seems like the data loss should be a separate issue from the UX issue..? The UX issue is probably captured at #2125117: [meta] Adding related issues needs major improvements, since both of these features use the same field type, afaik.
Comment #9
xjmWell, fixing both issues involves changing this one field's configuration, so it seems sensible to do in the same patch and unnecessary to artificially split out the second part of the original issue. If someone wants to move it into a followup that's fine too. It's not really related to #2125117: [meta] Adding related issues needs major improvements though; the field is configured differently from that field. This issue would just bring the functionality up to what's already deployed for issue nodes, rather than resolving any issue they have in common.
Maybe it'd be really easy to fix if the data is still in the table, but what if someone updates a change record? Are the additional issue reference records lost? Something to try on said dev environment and not in production. :) If they are lost, then we've already lost some data and will lose more as more change records are updated.
Comment #10
jthorson CreditAttribution: jthorson commentedSimply changing the issues cardinality to 'unlimited' on my dev site brought back the full list of issue references (except that they all came back as 'node not found', since the dev site node table is truncated).
Looks like we should be able to click-fix this in production, demote the status to normal, and leave open for a followup to modify the drupalorg feature configuration.
Comment #11
drummChange records are managed by features. We should click it on staging and export the new code to drupalorg module.
Comment #12
drummHow did this not get tagged?
Comment #13
drummComment #14
drummhttp://drupalcode.org/project/drupalorg.git/commit/0fff500 is deployed and many change notices, like https://drupal.org/node/2086767, are now fixed.
Unfortunately, change notices saved in the meantime have lost the data, including https://drupal.org/node/2116417. I'll see what I can recover.
As webchick said, the UX issue is #2125117: [meta] Adding related issues needs major improvements. Both this field and related issues are entity reference fields to issues.
Comment #15
drummWe lucked out on the old data. There was a custom direct migration from the old field to entityreference, and it did not clean up after itself. I can make a full recovery of the missing 313 references.
Comment #16
drummCorrection, there are only 41 missing rows, now all restored with http://drupalcode.org/project/drupalorg.git/commit/2026bf2. My initial query was too aggressive. These change records could use double checking to be sure the restored data is all good:
https://drupal.org/node/1272696
https://drupal.org/node/1534648
https://drupal.org/node/1539454
https://drupal.org/node/1722906
https://drupal.org/node/1880620
https://drupal.org/node/1909596
https://drupal.org/node/1989646
https://drupal.org/node/2023537
https://drupal.org/node/2034707
https://drupal.org/node/2040323
https://drupal.org/node/2064123
https://drupal.org/node/2116417
Comment #17
webchickThanks a lot for the fast turnaround on this, drumm!
Comment #18
nod_I can't add an issue to a change record anymore. For all nid I try I get a validation error: «There are no entities matching "xxx"».Nevermind, just seen the mention in issue summary.
Comment #19
webchickFixing title, also going back retroactively and tagging a few issues that could use some automated tests to ensure that they don't get introduced again.
Comment #20
xjmYAY. Thank you all so much! This is a huge relief.