Describe the bug
While investigating the issue DSpace/DSpace#12686 on the backend, I discovered that unnecessary logs are being created when a single value (or a subset of values) of a metadata with multiple values is modified.
For example, for an item with N authors (dc.contributor.author), if only one value is modified, there will be 2 * N_ audit records of type MODIFY_METADATA, one with the action ADD and another REMOVE for each value (even though only one was modified).
This happens because the front-end sends a PATCH with the body ["op": "add", "path": "/sections/publicationStep/dc.contributor.author", "value": [...]] where the complete list of values is sent again.
This causes the back-end to remove all metadata values and add them again, instead of just applying the modifications.
I'm not sure, however, whether this should be handled here on the front-end (sending a single 'replace' for the modified values) or perhaps on the back-end itself (checking if there was an actual change in the metadata value before creating the audit log).
To Reproduce
Steps to reproduce the behavior:
- Access an item with more than one value for a given metadata field.
- Change a single value from that group of metadata fields, or a subset of the values, and save the changes.
- Access the audit tab. There will be a pair of logs (ADD and REMOVE) for each value, including the values that remained the same.
Example:
Tested on this item, changing the name of the first author.
Those two opened logs below are the actual change, the other four are pairs of ADD and REMOVE for each one of the other values (not changed).
Expected behavior
Only metadata values that have actually been modified should generate a pair of audit logs (REMOVE + ADD).
Describe the bug
While investigating the issue DSpace/DSpace#12686 on the backend, I discovered that unnecessary logs are being created when a single value (or a subset of values) of a metadata with multiple values is modified.
For example, for an item with N authors (dc.contributor.author), if only one value is modified, there will be 2 * N_ audit records of type MODIFY_METADATA, one with the action ADD and another REMOVE for each value (even though only one was modified).
This happens because the front-end sends a PATCH with the body
["op": "add", "path": "/sections/publicationStep/dc.contributor.author", "value": [...]]where the complete list of values is sent again.This causes the back-end to remove all metadata values and add them again, instead of just applying the modifications.
I'm not sure, however, whether this should be handled here on the front-end (sending a single 'replace' for the modified values) or perhaps on the back-end itself (checking if there was an actual change in the metadata value before creating the audit log).
To Reproduce
Steps to reproduce the behavior:
Example:
Tested on this item, changing the name of the first author.
Those two opened logs below are the actual change, the other four are pairs of ADD and REMOVE for each one of the other values (not changed).
Expected behavior
Only metadata values that have actually been modified should generate a pair of audit logs (REMOVE + ADD).