fix: improve 'move' handling of controls in form array

[jlipka]

References

• Fixes #4418
• Might also fix the described behaviour in #4736

Description

If a form element is repeatable, the values in the form array will no longer become disorganised when items are moved or deleted from the list in multiple operations. Each individual operation does not necessarily cause a problem, but if one operation is performed after another, the final values may not be correctly sent to the backend due to wrong values used in the form-array.

Instructions for Reviewers / Steps to reproduce

Create a list of six items in a repeatable form control field, e.g. "Other titles". Enter values from 1 to 6. Now, move the last item (value: 6) to second place. Remove this moved item (from the second place). Move the new last item (value: 5) to the first place, then move the item with the "value: 4" to the first place, followed by pressing (the first time) the Save button. Check the corresponding PATCH request as also the form itself for the correct values and their sorting order. To double-check the correct data, hard-reload the submission to verify the values and their order are still right. The result should look like "4, 5, 1, 2, 3".

Before this patch, the result after pressing the Save button was: "5, 6, 1, 3 ,4" - in the PATCH request payload, as well in the form itself after the request was processed. This behaviour ist reproducable on the demo.dspace.org and sandbox.dspace.org pages using a workspace or workflow item.

To ensure that no new errors are introduced, I would be grateful if the reviewer(s) could carry out a few checks. For example, could you check that repeatable fields with controlled vocabularies are also still saved correctly alongside regular input fields, and that relationships between entities within a list are still saved the right way.

List of changes in this PR:

• Refactored control retrieval logic by replacing getControlOfGroup with direct use of control.get and using the regular index instead of startingIndex
• Added moveFormControlToPosition method to handle control positioning during drag-and-drop operations. Ensured controls remain correctly linked to their respective groups

Checklist

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• My PR aligns with Accessibility guidelines if it makes changes to the user interface.
• My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
• My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.

[kanasznagyzoltan]

I have tested, it worked for me.

pr_4763.mp4

[tdonohue]

Temporarily closing & reopening to trigger tests to rerun. This PR never seems to have run the tests for Node 22.

[lgeggleston]

+1, looks good to me as well! (Note: Test and not a full code review).

Confirmed the main fix of not re-ordering on a save, with several different repeatable fields (Other titles, Type, Author). The order remains consistent after archiving the item as well. Tried some random edits to repeatable fields and did not see regressions.

[tdonohue]

👍 Thanks @jlipka ! With your instructions in this PR, I was able to reproduce the bug on Sandbox. I've verified this fixes the bug. I did some of my own complex reordering of values and couldn't find a way to break anything anymore. So, I'm not seeing any regression issues either. Code looks good too!

[dspace-bot]

Backport failed for dspace-7_x, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin dspace-7_x
git worktree add -d .worktree/backport-4763-to-dspace-7_x origin/dspace-7_x
cd .worktree/backport-4763-to-dspace-7_x
git switch --create backport-4763-to-dspace-7_x
git cherry-pick -x e7212843e988b2c2f6ddcfd31f2d16560192b348

[dspace-bot]

Backport failed for dspace-8_x, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin dspace-8_x
git worktree add -d .worktree/backport-4763-to-dspace-8_x origin/dspace-8_x
cd .worktree/backport-4763-to-dspace-8_x
git switch --create backport-4763-to-dspace-8_x
git cherry-pick -x e7212843e988b2c2f6ddcfd31f2d16560192b348

[dspace-bot]

Successfully created backport PR for dspace-9_x:

• [Port dspace-9_x] fix: improve 'move' handling of controls in form array #5729

[tdonohue]

@jlipka : This was only able to be auto-backported to 9.x. However, that's all we require for bug fixes (we only require backports to the latest major version). If you (or anyone else) would like to see this fix in earlier releases (8.x or 7.x), please create a separate backport PR against the dspace-8_x or dspace-7_x branch.