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

eliza411’s picture

eliza411 commented
Issue tags: +D.o UX

Looks like there are two tags out there. D.o UX is in wider use atm, so I'm adding it.

yoroy’s picture

yoroy commented
Issue tags: +Usability

And the UX catch-all tag :)

xjm’s picture

xjm
she/her
Primary language English
commented
Title: UX Regression: Change record issue reference field is hard to use » DATA LOSSS and UX Regression: Change record issue reference field is hard to use
Issue summary: View changes
Priority: Normal » Critical
Issue tags: -D.o UX +drupal.org UX

Just 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.

xjm’s picture

xjm
she/her
Primary language English
commented
Title: DATA LOSSS and UX Regression: Change record issue reference field is hard to use » DATA LOSS and UX Regression: Change record issue reference field is hard to use

Got a bit smashy on the keyboard there.

xjm’s picture

xjm
she/her
Primary language English
commented
Issue tags: -drupal.org UX +D.o UX
mcrittenden’s picture

mcrittenden commented
Issue tags: -Usability

In that case, removing the Usability tag.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

The 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.

xjm’s picture

xjm
she/her
Primary language English
commented

Well, 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.

jthorson’s picture

jthorson commented

Simply 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.

drumm’s picture

drumm
he/him
Location NY, US
commented

Change records are managed by features. We should click it on staging and export the new code to drupalorg module.

drumm’s picture

drumm
he/him
Location NY, US
commented
Issue tags: +Drupal.org 7.1

How did this not get tagged?

drumm’s picture

drumm
he/him
Location NY, US
commented
Assigned: Unassigned » drumm
drumm’s picture

drumm
he/him
Location NY, US
commented

http://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.

drumm’s picture

drumm
he/him
Location NY, US
commented

We 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.

drumm’s picture

drumm
he/him
Location NY, US
commented
Status: Active » Fixed

Correction, 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

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Thanks a lot for the fast turnaround on this, drumm!

nod_’s picture

nod_
Primary language French
Location Lille
commented

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.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Title: DATA LOSS and UX Regression: Change record issue reference field is single-value and hard to use » DATA LOSS: Change record issue reference field is single-value
Issue tags: +Needs tests

Fixing 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.

xjm’s picture

xjm
she/her
Primary language English
commented

YAY. Thank you all so much! This is a huge relief.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.