Describe the bug
PR #11964 introduces granular metadata-level security / metadata visibility controls, and the review notes indicate that metadata visibility should match the configured security levels.
However, this appears to be enforced only on the Item view level. The same protected metadata is still exposed through other outputs/endpoints, including:
It would be better if the full framework introduced in this PR were consistently folded into MetadataExposureService (or the other way around, remove MetadataExposureService & keep MetadataSecurityServiceImpl) and used by all metadata serialization/export endpoints, so that metadata visibility rules are enforced uniformly across DSpace. I believe in the end only one class should remain & handle both configurations.
This will ensure that we don't reintroduce this bug if new metadata exposure output/endpoints are added.
To Reproduce
Steps to reproduce the behavior:
- Configure the metadata visibility on a Publication level metadata field that is widely used (dc.description.abstract for example)
- Submit an item & restrict the field to admin only view
- Check OAI for example & the field will be fully public there.
Expected behavior
Expected behavior: metadata hidden by the configured metadata security rules should also be excluded from all export/serialization endpoints, not only from the Item view.
Describe the bug
PR #11964 introduces granular metadata-level security / metadata visibility controls, and the review notes indicate that metadata visibility should match the configured security levels.
However, this appears to be enforced only on the Item view level. The same protected metadata is still exposed through other outputs/endpoints, including:
It would be better if the full framework introduced in this PR were consistently folded into MetadataExposureService (or the other way around, remove MetadataExposureService & keep MetadataSecurityServiceImpl) and used by all metadata serialization/export endpoints, so that metadata visibility rules are enforced uniformly across DSpace. I believe in the end only one class should remain & handle both configurations.
This will ensure that we don't reintroduce this bug if new metadata exposure output/endpoints are added.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Expected behavior: metadata hidden by the configured metadata security rules should also be excluded from all export/serialization endpoints, not only from the Item view.