Setting to configure whether editor users who are metadata owners can edit their metadata when they do not have editing privileges for the metadata. #8631
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change adds a new setting to configure whether editor users who are metadata owners can edit their metadata when they do not have editing privileges for the metadata.
By default, the setting is enabled to preserve the original behavior in GeoNetwork: editor users can edit a metadata if they are the owner of the metadata or have editing privileges in any of the groups where they have the editor profile. For most users it is not necessary to change this setting.
When the setting is disabled a user with editor profile can only edit a metadata if has edit privileges in any of the groups where has the Editor role.
The setting doesn't affect Administrator users, that can always edit the metadata.
The pull request contains Sonarlint code improvements.
Checklist
I have read the contribution guidelines
Pull request provided for
main
branch, backports managed with labelGood 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
filesLibrary management using
pom.xml
dependency management. Update build documentation with intended library use and library tutorials or documentationFunded by IFremer