[DSpace-CRIS] Duplicate "Custom URLs" can be created from the "Edit Item -> Metadata" screen because of lack of validation

[tdonohue]

Warning

This ticket describes a blocker issue discovered during testing of #4814 and DSpace/DSpace#11549
As a blocker, it must be resolved prior to 10.0 (its assigned milestone)

Describe the bug

In testing of #4814 and DSpace/DSpace#11549, we discovered that it's possible to create duplicate "Custom URLs" by editing the dspace.customurl metadata value from the "Edit Item -> Metadata" screen.

When duplicate "Custom URLs" are created, both Entities using that Custom URL will fail to load in the User Interface and instead you'll see this message:

When both items are in that state, they can only be fixed by logging in as an Administrator and going straight to the "Edit" page for the item by typing the full URL in your browser window, e.g. http://localhost:4000/entities/publications/[uuid]/edit From there, you'd have to edit the dspace.customurl metadata field for one item to non-duplicative value.

To Reproduce

Steps to reproduce the behavior:

1. Create two new Publications with the Custom URL feature enabled. By default, they will have different Custom URLs, even if their dc.title field is identical. Note down the two custom URL values.
2. Login as an Admin
3. Visit one of those Publications and Edit it.
4. Go to the "Metadata" tab.
5. Edit the dspace.customurl metadata field to set it to the same Custom URL as the other Publication.
6. Save the value.
7. Go back to either Publication's page. It will no longer load and you'll see the "Error fetching item" message.

Expected behavior

It should not be possible to duplicate Custom URLs. This can be fixed in either of these two ways:

• Either validation should be added to the "Edit Item -> Metadata" page to ensure that a duplicate dspace.customurl value cannot be saved.
• Or, alternatively, it should not be possible to edit the dspace.customurl (or dspace.customurl.old) metadata fields from the "Edit Item -> Metadata" page.
  • This might be achieved similar to how Virtual Metadata fields are displayed on the "Metadata" tab but are not editable there.

Related work

#4814 and DSpace/DSpace#11549