Update db search and replace to support working copies

[tylerjmchugh]

Currently the db search and replace API does not support working copies. This means that when we try to create a working copy and apply the search and replace on it, the working copy is ignored and the change is applied directly to the approved version.

This PR aims to fix this by implementing the following logic:

• If the record is a draft
  • Update the draft record
• If the record is approved (with no working copy)
  • Update the approved record
• If the record is approved (with a working copy)
  • Update the working copy

Checklist

• I have read the contribution guidelines
• Pull request provided for main branch, backports managed with label
• Good housekeeping of code, cleaning up comments, tests, and documentation
• Clean commit history broken into understandable chucks, avoiding big commits with hundreds of files, cautious of reformatting and whitespace changes
• Clean commit messages, longer verbose messages are encouraged
• API Changes are identified in commit messages
• Testing provided for features or enhancements using automatic tests
• User documentation provided for new features or enhancements in manual
• Build documentation provided for development instructions in README.md files
• Library management using pom.xml dependency management. Update build documentation with intended library use and library tutorials or documentation

[josegar74]

@tylerjmchugh I got a bizarre case with the working copy:

• Created a metadata with a contact individual name Jose and approved it.

• Edited it to create a working copy and changed the title to distinguish the metadata in batch edit XML preview.

• Replaced Jose with Jose 1: updates the value in the working copy, but not in the approved version (correct).

The preview XML shows the correct replaced value, but the metadata title is the approved one. It seems the preview doesn't use the working copy. This should be checked.

• I updated again the metadata to change Jose 1 to Jose 2, but then the working copy is updated with the approved version value Jose instead of Jose 2

[tylerjmchugh]

@josegar74

The preview XML shows the correct replaced value, but the metadata title is the approved one. It seems the preview doesn't use the working copy. This should be checked.

I updated again the metadata to change Jose 1 to Jose 2, but then the working copy is updated with the approved version value Jose instead of Jose 2

It seems the search and replace logic was applying the changes to the correct version but behind the scenes it was searching for the UUID on the MetadataRepository to get the updated metadata rather than using an IMetadataUtils method. I updated the draft repository to include the search and replace methods like the metadata repository has and implemented it in IMetadataUtils.

These issues now seem to be resolved but I see a unit test is now failing for the regex replace. I will look into this.

[tylerjmchugh]

Fixed the unit test failure and issues with regex. Ready for review.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[josegar74]

Tested the changes and works fine.

[geonetworkbuild]

The backport to 4.2.x failed:

The process '/usr/bin/git' failed with exit code 1

stderr

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Otherwise, please use 'git cherry-pick --skip'

stdout

[backport-8514-to-4.2.x 2df3c6bb68] Update db search and replace API to allow replacements on working copies
 Author: tylerjmchugh <[email protected]>
 Date: Tue Nov 26 10:33:04 2024 -0500
 1 file changed, 16 insertions(+), 3 deletions(-)
[backport-8514-to-4.2.x 8bd68ca3e7] Remove param
 Author: tylerjmchugh <[email protected]>
 Date: Tue Nov 26 12:16:30 2024 -0500
 1 file changed, 3 insertions(+), 16 deletions(-)
On branch backport-8514-to-4.2.x
You are currently cherry-picking commit f9b67accf7.
  (all conflicts fixed: run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

nothing to commit, working tree clean

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-4.2.x 4.2.x
# Navigate to the new working tree
cd .worktrees/backport-4.2.x
# Create a new branch
git switch --create backport-8514-to-4.2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick e0c2829e33a1d0935bf3624bf020060505fa522b,c8ac524846b521fb34dc762ec64724bb73852ec1,f9b67accf76db0d0574d58eece5bf772cf3ae9ac,3b817274da8a4c34b1056fabb14450f1d42ef21b,f49e6f71dfcfcb932e7569ba12f52503e5025c42,762120e03c21fc3cbbbe3bf1a3ea5569449a53b0,8d09f1cd244a266111b6120c6fd61fb5777b3cb2,debe4396fc36c0bfb65d7afb14051f3a8ea1fa04,3be79184dba6a972da59602f87129f358a74a7fe
# Push it to GitHub
git push --set-upstream origin backport-8514-to-4.2.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-4.2.x

Then, create a pull request where the base branch is 4.2.x and the compare/head branch is backport-8514-to-4.2.x.