Faulty submission form: arrange more than 3 lines

[Verena-HSU]

The rearrangement of more than 3 lines in the submission form is faulty. Rows disappear in the display (they are there again when saving) or are arranged differently than specified.

This has been tested with Chrome version 126.0.6478.183 (Offizieller Build) (64-Bit) on Dspace 8 demo version with the following item:
https://demo.dspace.org/workspaceitems/2168/view

Scenario:

1. Open a submission form
2. Add three or more rows with authors or keywords or else
3. Rearange the lines several times.

--> Sometimes lines will disappear, sometimes arrange in a different order.

Expected behaviour:

Lines will always appear und in the chosen order.

[kshepherd]

I have been seeing this in 7.6 and 8.0 as well.

I believe that after a reorder, the displayed text for the form oneboxes do not always match the underlying [Reorderable]MetadataValue that is used in patch add/update/delete operations.

1. It seems to be more consistently reproducible if neither of the fields being 'switched' in the reorder are the first or last field (as of last save / current form state)
2. It happens with both plain metadata values and controlled values, or a mixture of both, I think? But I think it's only happening for fields/models that are configured as controlled vocab / authority fields (ie. implementing DynamicVocabularyComponent)
3. The actual values are in the order they were moved. If you click 'Save' and reload the page, the values will appear in the order that they were moved to, with matching display text / labels.

Here are five author entries I made to demonstrate this on the DSpace Demo server - the 4th is a controlled value:

Here is what is displayed after I reorder the 4th and 3rd values - they are switched but the label for the "Four Friends" entry has now been rendered as "Three".

After clicking Save to perform the patch updates, and reloading the page, I can see that the reordering was successful, the displayed text in the form was just incorrect:

I think the problem is in the DynamicOnebox component, when subscribing to value changes -- it sees a value change, and overwrites currentValue to the model value. I think this is because the subs are treating this.model.id as a persistent index, instead of allowing for a group index that changes after reorders...

this.subs.push(this.group.get(this.model.id).valueChanges.pipe(...)

This subscription was added in August 2020 when submission and controlled vocab code was quite new, and if it still does something useful then we need to make sure that the subscriptions are build in a way that allow for the fact that groups.get(x) will change as x (the index of the groups array) changes, after reordering.

I believe the behaviour reported in #2004 (unreliable save/delete) is related to the same issue - the saves and deletes are probably actually doing "the right thing" but do not match user expectations because the displayed text in the form components doesn't match the actual existing value to be saved/deleted.

Note: I have not tested this extensively with "ExistingMetadataListValueComponent" which are actually relationship representations and are handled quite differently to form controls backed by saved metadata objects.

[jlipka]

I have mentioned my idea/solution in the other Github issue (#2004), please have a look if this could help here as well:
#2004 (comment)

[kshepherd]

I have mentioned my idea/solution in the other Github issue (#2004), please have a look if this could help here as well: #2004 (comment)

Just to note my comment here, too, the fix mentioned in #2004 is good on its own merit (fixing bad equality checking) but only affects existing relationships being patched/saved from a submission, not onebox metadata values being re-ordered in an active submission.