[DSpace-CRIS] Administrative Edit of archived items via submission form and security configuration for metadata visibility (Backend)

[AdamF42]

References

• Fixes [DSpace-CRIS] Administrative Edit of archived items via submission form and security configuration for metadata visibility #12166
• Requires frontend PR [DSpace-CRIS] Administrative Edit of archived items via submission form and security configuration for metadata visibility (Frontend) dspace-angular#5145
• Related to [DSpace-CRIS] Porting of authority framework functionalities (Backend) #11718, [DSpace-CRIS] Nested / Basic Hierarchical Metadata (Backend) #11945, [DSpace-CRIS] Inverse Relations via Authority Framework (Backend) #11963
• Related to RestContract

Description

This PR ports the Edit Mode feature set from DSpace-CRIS to DSpace core. It enables a submission-like editing experience for archived items with granular security controls, shared workspaces, and enhanced access management. This feature set allows users to edit archived items using familiar submission forms while maintaining proper security and validation.

Note: This PR is part of the DSpace-CRIS merger effort and depends on previous PRs in the series ( #11718, #11945, #11963).

---

Instructions for Reviewers

List of changes in this PR:

Feature 1: Granular Edit/Security Privileges (#3 in "Feature Differences"))

• First, added EditItemMode configuration system that allows defining multiple edit modes per entity type with different security levels (ITEM_ADMIN, OWNER, CUSTOM, GROUP, ANONYMOUS).
• Second, implemented CrisSecurityService for evaluating complex security policies based on user roles, item ownership, and custom metadata fields.
• Third, created EditItemModeValidator to ensure edit mode names are unique per entity type and properly configured.
• Fourth, implemented granular metadata-level security with configurable access levels:
  • Level 0: Public access
  • Level 1: Group-based access (e.g., "Trusted" group)
  • Level 2: Administrator and owner only

Feature 2: Edit Item in Submission Mode (#9 in "Feature Differences")

• First, created EditItem and EditItemRest models to represent archived items in an editable state similar to WorkspaceItems.
• Second, implemented EditItemService for managing the edit lifecycle of archived items including validation and state management.
• Third, created EditItemRestRepository with full REST API support for:
  • Retrieving archived items in editable format
  • Patching metadata changes
  • Managing bitstreams and access conditions
  • Validating changes before saving
• Fourth, added EditItemConverter to transform archived items into submission-like structures with sections and validation.
• Fifth, implemented UnprocessableEditException to handle validation errors gracefully, refusing to save items in invalid states.
• Sixth, enhanced ValidationService to use the correct submission definition from the edit mode configuration rather than the default collection submission.

Feature 3: Shared Workspaces (#14 in "Feature Differences")

• First, integrated shared workspace logic allowing multiple users to collaborate on editing the same item.
• Second, added isSharedWorkspace checks to determine if an item can be accessed by users other than the submitter/owner.
• Third, implemented proper authorization controls to ensure only authorized users can access shared workspace items based on security configuration.

Feature 4: Authors can download restricted bitstreams (#13 in "Feature Differences")

• First, implemented enhanced bitstream access control allowing item authors to download restricted bitstreams.
• Second, integrated with the granular security system to check user relationships with the item before granting access.

Feature 5: Submission forms and workflow linked to collection via UI (#29 in "Feature Differences")

• First, added support for collection metadata dspace.submission.definition to bind specific submission form definitions to collections.
• Second, implemented SubmissionConfigReader enhancement to look up the submission definition from collection metadata.
• Third, updated collection edit page to allow administrators to customize submission form definitions via UI or API.

---

Testing/Review Guidance:

Prerequisites

1. Configure edit modes in dspace/config/spring/api/edititem-service.xml
2. Configure metadata security levels in dspace/config/spring/api/spring-dspace-security-metadata.xml
3. Configure relationship authorizers in dspace/config/spring/api/relationship-authorizers.xml
4. Add submission form definitions for entities you want to test

Test Scenarios

Test 1: Edit Item as Administrator

1. Find an archived publication item
2. Access /api/core/edititems/{item-uuid}
3. Verify the item is returned with submission-like structure
4. Make metadata changes via PATCH
5. Verify changes are saved and item remains valid

Test 2: Edit Item as Owner

1. Configure a Person entity type with OWNER security level
2. Access edit item endpoint as the item owner
3. Verify owner can edit with appropriate permissions
4. Verify non-owners cannot access the edit endpoint

Test 3: Granular Metadata Security

1. Configure metadata fields with different security levels (0, 1, 2)
2. Access item as different user types (anonymous, group member, owner, admin)
3. Verify metadata visibility matches security configuration

Test 4: Collection-Linked Submission Forms

1. Set dspace.submission.definition metadata on a collection
2. Create/edit an item in that collection
3. Verify the correct submission form is used

Test 5: Relationship Authorization

1. Create a relationship between items (e.g., Person-Funding)
2. Test access as the related item owner
3. Verify authorization based on relationship configuration

Test 6: Access Condition Management

1. Edit an archived item's access conditions
2. Add custom policies without append mode
3. Verify INHERITED policies are removed
4. Remove all custom policies
5. Verify default collection policies are restored

---

Required Configuration

1. Edit Item Service Configuration (dspace/config/spring/api/edititem-service.xml)

Define edit modes for each entity type:

<bean class="org.dspace.content.edit.service.impl.EditItemModeServiceImpl">
    <property name="editModesMap">
        <map>
            <entry key="publication">
                <list>
                    <bean class="org.dspace.content.edit.EditItemMode">
                        <property name="name" value="FULL" />
                        <property name="security">
                            <value type="org.dspace.content.security.CrisSecurity">
                                ITEM_ADMIN
                            </value>
                        </property>
                        <property name="submissionDefinition" value="publication-edit" />
                    </bean>
                </list>
            </entry>
            <entry key="person">
                <list>
                    <bean class="org.dspace.content.edit.EditItemMode">
                        <property name="name" value="FULL" />
                        <property name="security" value="ITEM_ADMIN" />
                        <property name="submissionDefinition" value="admin-person-edit" />
                    </bean>
                    <bean class="org.dspace.content.edit.EditItemMode">
                        <property name="name" value="OWNER" />
                        <property name="security" value="OWNER" />
                        <property name="submissionDefinition" value="person-edit" />
                    </bean>
                </list>
            </entry>
            <entry key="funding">
                <list>
                    <bean class="org.dspace.content.edit.EditItemMode">
                        <property name="name" value="FULL" />
                        <property name="security" value="ITEM_ADMIN" />
                        <property name="submissionDefinition" value="funding-edit" />
                    </bean>
                    <bean class="org.dspace.content.edit.EditItemMode">
                        <property name="name" value="INVESTIGATOR" />
                        <property name="security" value="CUSTOM" />
                        <property name="submissionDefinition" value="funding-edit" />
                        <property name="items">
                            <list>
                                <value>crisfund.investigators</value>
                            </list>
                        </property>
                    </bean>
                </list>
            </entry>
        </map>
    </property>
</bean>

Security Levels:

• ITEM_ADMIN: Only item administrators
• OWNER: Item owner only
• CUSTOM: Based on metadata fields (e.g., investigators, editors)
• GROUP: Specific user group
• ANONYMOUS: All users

2. Metadata Security Configuration (dspace/config/spring/api/spring-dspace-security-metadata.xml)

<util:map id="securityLevelsMap">
    <entry key="0" value-ref="level0Security"/>
    <entry key="1" value-ref="level1Security"/>
    <entry key="2" value-ref="level2Security"/>
</util:map>

<bean id="level0Security" class="org.dspace.content.MetadataPublicAccess"/>
<bean id="level1Security" class="org.dspace.content.MetadataGroupBasedAccess">
    <property name="egroup" value="Trusted"/>
</bean>
<bean id="level2Security" class="org.dspace.content.MetadataAdministratorAndOwnerAccess"/>

3. Collection Submission Definition Binding

Via REST API:

curl 'https://dspace.example.com/server/api/core/collections/{uuid}' \
  -X PATCH \
  -H 'Content-Type: application/json' \
  --data-raw '[
    {"op":"replace","path":"/metadata/dspace.submission.definition","value":{"value":"publication"}}
  ]'

4. Entity Type Submission Definitions

Add to item-submission.xml:

<submission-process name="funding">
    <step id="collection"/>
    <step id="fundingStep"/>
</submission-process>

Add corresponding forms to submission-forms.xml:

<form name="funding-edit">
    <row>
        <field>
            <dc-schema>crisfund</dc-schema>
            <dc-element>title</dc-element>
            <label>Title</label>
            <input-type>onebox</input-type>
            <required>You must enter a title.</required>
        </field>
    </row>
</form>

---

API Endpoints

Edit Item Endpoints

Get edit item (submission-like format):

GET /api/core/edititems/{item-uuid}

Get available edit modes for an item:

GET /api/core/edititems/{item-uuid}/modes

Patch edit item (metadata changes):

PATCH /api/core/edititems/{item-uuid}
Content-Type: application/json
[
  {"op": "add", "path": "/sections/describe/dc.title/0", "value": {"value": "New Title"}}
]

Delete edit item (discard changes):

DELETE /api/core/edititems/{item-uuid}

Metadata Value Endpoints (with security)

Metadata values now include security level information:

{
  "id": "12345",
  "value": "Secret information",
  "securityLevel": "2",
  "display": "ADMINISTRATOR_AND_OWNER"
}

Checklist

This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome).
However, reviewers may request that you complete any actions in this list if you have not done so. If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & integration tests). Exceptions may be made if previously agreed upon.
• My PR passes Checkstyle validation based on the Code Style Guide.
• My PR includes Javadoc for all new (or modified) public methods and classes. It also includes Javadoc for large or complex private methods.
• My PR passes all tests and includes new/updated Unit or Integration Tests based on the Code Testing Guide.
• My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
• If my PR includes new libraries/dependencies (in any pom.xml), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR modifies REST API endpoints, I've opened a separate REST Contract PR related to this change.
• If my PR includes new configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.

[tdonohue]

@AdamF42 : Which DSpace-CRIS feature is this on the differences list? We need to link this up to one of the tickets, and I'm trying to understand which ticket this relates to. Is this related to #11749?

UPDATE: Never mind, as I look at this closer, I realize this appears to be at least part of #11749

[KevinVdV]

@AdamF42 I performed a quick code review (see below), however to fully understand how things tie together it would be good to test it with the UI. Is there an ANGULAR PR open for this anywhere ?

The code review

Issue 1

Why is there a separate "RelatedItemEnhancerUpdatePoller" dispatcher in the dspace.cfg, the consumer list appears to be the same, maybe we can remove this ?
If you remove this, make sure to remove the setDispatcher() call to in the RelatedItemEnhancerUpdatePollerclass.

Issue 2

I noticed the inline-group input-type in the DCInputSetclass, this only appears in the IT's to test that the parsing works. Maybe this was mistakenly ported in this PR as the description doesn't mention it ?

Issue 3

The SubmissionConfigReader.getCorrectionSubmissionConfigByCollection() method doesn't appear to be used.

Issue 4

The getSubmissionConfigByCollection(String collectionHandle) & getSubmissionConfigByCollection(Collection collection) work a bit differently, could this not have unintended side effects ?

• collectionHandle method retrieves the collection based on the handle with a fallback on the default
• collection object method retrieves it based on the metadata override (if any) & then proceeds to by name
  Would it not make sense for the collectionHandle method to link through to the one by collection ? Otherwise depending on the method you might get a different configuration.

Issue 5

The DiscoverQuery & DiscoverQueryBuilder class were modified to include a scope object, this scope object isn't used.

[AdamF42]

@AdamF42 I performed a quick code review (see below), however to fully understand how things tie together it would be good to test it with the UI. Is there an ANGULAR PR open for this anywhere ?

The code review

Issue 1

Why is there a separate "RelatedItemEnhancerUpdatePoller" dispatcher in the dspace.cfg, the consumer list appears to be the same, maybe we can remove this ? If you remove this, make sure to remove the setDispatcher() call to in the RelatedItemEnhancerUpdatePollerclass.

Issue 2

I noticed the inline-group input-type in the DCInputSetclass, this only appears in the IT's to test that the parsing works. Maybe this was mistakenly ported in this PR as the description doesn't mention it ?

Issue 3

The SubmissionConfigReader.getCorrectionSubmissionConfigByCollection() method doesn't appear to be used.

Issue 4

The getSubmissionConfigByCollection(String collectionHandle) & getSubmissionConfigByCollection(Collection collection) work a bit differently, could this not have unintended side effects ?

* collectionHandle method retrieves the collection based on the handle with a fallback on the default

* collection object method retrieves it based on the metadata override (if any) & then proceeds to by name
  Would it not make sense for the `collectionHandle` method to link through to the one by collection ? Otherwise depending on the method you might get a different configuration.

Issue 5

The DiscoverQuery & DiscoverQueryBuilder class were modified to include a scope object, this scope object isn't used.

@KevinVdV, thank you for the code review. Here's the status of each issue:

Issue 1 - Came from #11718 (does not belong to this pr)

Issue 2 - Came from #11945 (inline-group input-type handling)

Issue 3 - You were correct, I've removed the unused getCorrectionSubmissionConfigByCollection() method

Issue 4 - You were right about the inconsistency. I've removed the unused getSubmissionConfigByCollection(String collectionHandle) method and improved the Javadoc for the remaining method to clarify the lookup behavior (metadata override → by name → default fallback)

Issue 5 - You were correct, the scope object came from #11963 and wasn't being used. I've removed it from both DiscoverQuery and DiscoverQueryBuilder

---

Regarding the Angular frontend PR: I've now linked the corresponding frontend PR in the description. However, I suggest reviewing this PR after the other PRs in the dependency chain (#11718, #11945, #11963) are addressed, as this PR builds on top of those changes.

[github-actions]

Hi @AdamF42,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

[KevinVdV]

Made an initial not too deep review to see what the features are about, you can find my feedback below.

Issue 1

Tried to create a collection & got an exception:

Caused by: java.sql.SQLException: bad_dublin_core schema=cris.submission.definition. Metadata field does not exist!

After testing more I also found the following metadata fields are missing (full list):

• cris.submission.definition
• cris.submission.definition-correction
• cris.workspace.shared

Issue 2

You cannot create a collection without entities anymore, the entity type is mandatory (even if you have a clean database without any entities setup)

Issue 3

When I start a new submission any metadata I add gets lost after pressing the save button. The PATCH request is properly fired, but the item that is returned doesn't contain any of the metadata that I added.
So I can't finish a submission at this point.

Questions

Question 1

When creating a collection the "Submission definition" is mandatory, if we want to do things like this we either need to:

• Make it optional
• If we keep it mandatory
  • Create a migration script that will set the submission definition on the collections based on the submission-forms.xml
  • I would also then remove the configuration from the submisssion-forms.xml (because any new collections will have it set through the UI)
  • Support in the struct-builder would also be very useful (we already have it for the shared workspace)

Question 2

The feature set for this PR mentions: Granular Edit/Security Privileges , how can I test this from the UI ? As the ANGULAR PR doesn't mention this. The traces I find in the REST side indicate that the security level is set through the PATCH command.

[AdamF42]

Made an initial not too deep review to see what the features are about, you can find my feedback below.

Issue 1

Tried to create a collection & got an exception:

Caused by: java.sql.SQLException: bad_dublin_core schema=cris.submission.definition. Metadata field does not exist!

After testing more I also found the following metadata fields are missing (full list):

* cris.submission.definition

* cris.submission.definition-correction

* cris.workspace.shared

Issue 2

You cannot create a collection without entities anymore, the entity type is mandatory (even if you have a clean database without any entities setup)

Issue 3

When I start a new submission any metadata I add gets lost after pressing the save button. The PATCH request is properly fired, but the item that is returned doesn't contain any of the metadata that I added. So I can't finish a submission at this point.

Questions

Question 1

When creating a collection the "Submission definition" is mandatory, if we want to do things like this we either need to:

* Make it optional

* If we keep it mandatory
  
  * Create a migration script that will set the submission definition on the collections based on the submission-forms.xml
  * I would also then remove the configuration from the submisssion-forms.xml (because any new collections will have it set through the UI)
  * Support in the struct-builder would also be very useful (we already have it for the shared workspace)

Question 2

The feature set for this PR mentions: Granular Edit/Security Privileges , how can I test this from the UI ? As the ANGULAR PR doesn't mention this. The traces I find in the REST side indicate that the security level is set through the PATCH command.

Issue 1: Schema Migration Issue

The schema cris was migrated to dspace schema after the rebase onto main. The frontend was not updated accordingly, causing the issue. Now it is fexed on the angular side. Try with the updated version.

---

Issue 2: Mandatory Entity Type

This issue has been fixed on the Angular side.

---

Issue 3: Lost Method During Rebase

During the rebase, a mistake was made resulting in the loss of org.dspace.content.ItemServiceImpl#addMetadataInPlaceSecured. I've restored the method.

---

Question 2: Testing "Granular Edit/Security Privileges"

The frontend PR has been updated to include information for testing the "Granular Edit/Security Privileges" feature.

[AdamF42]

Hi @KevinVdV, thank you for the thorough review! Here are my responses to your feedback:

Issue 5 - CrisConstants class

We decided to keep those constants in a separate CrisConstants file since they are related to CRIS extension functionality and provide better organization for CRIS-specific configuration values.

Issue 6 - Unused Resource Policy code

I've removed the unused code:

• ResourcePolicyService.findValidPolicyOwners()
• ResourcePolicyServiceImpl.findValidPolicyOwners()
• ResourcePolicyDAO.findValidPolicyOwners()
• ResourcePolicyDAOImpl.findValidPolicyOwners()
• ResourcePolicyOwnerVO class

Issue 7 - DSpaceControlledVocabulary modifications

The DSpaceControlledVocabulary class was modified to fix an XPath injection vulnerability identified in this code scanning alert: #11964 (review).

The code was using String.format() to inject user-provided authority keys directly into XPath queries.
I changed the XPath templates from using %s format placeholders to using XPath variable placeholders ($nodeId).

Then created secure helper methods (getNodeByIdFromXPath() and getChoicesByXpathWithId()) that use XPathVariableResolver to bind user input as a variable value rather than concatenating it into the query structure.

Issue 8 - Metadata security usage

The metadata security system is being used, but the integration happens through the MetadataSecurityServiceImpl class. I added the securityLevelsMap injection and the isMetadataValueReturnAllowed() method that actually uses these security evaluators.

Issue 9 - ExtractMetadataStepException

Removed ExtractMetadataStepException - you're correct that it wasn't being thrown anywhere.

Issue 10 - admin.rest.properties.exposed

You're right - I've removed the usage of admin.rest.properties.exposed since it's not strictly required for this PR.

Question around BitstreamCrisSecurityService

"Authors can download restricted bitstreams" refers to the frontend PR DSpace/dspace-angular#5132 with testing instructions.

Regarding your concern about READ policies - could you clarify which specific code changes are concerning?

The intent is to allow item authors/owners to download their own bitstreams even when they have embargo/restriction policies, but this should not affect how READ policies work for other users.

Question around RelationshipAuthorizer

I updated the initial PR description to remove the RelationshipAuthorizer mention since that code has been removed from this PR.

[tdonohue]

@AdamF42 : Thanks for your work on this PR. Just a friendly note to say that only the first 15 (of about 60) inline comments have been addressed in my prior review. I'm assuming you are working on the others already, but I wanted to point this out in case the other comments were overlooked (because GitHub collapses that many comments so that most are not visible until you click "Load more..").

Thanks for what you've done so far though. It all looks good!

[KevinVdV]

@AdamF42 Thanks for looking into my feedback, approving this PR 👍

That said, I consider two issues I opened to be blocking, as they raise concerns around consistent metadata exposure enforcement and restricted bitstream authorization/auditability. These should be addressed before the release of DSpace 10.

• #12178
• #12179

[tdonohue]

Thanks @AdamF42 for all your hard work on this PR over the last few days!

I've retested today and everything is working well.

I've also verified that almost all of my prior feedback has been addressed. The only feedback that still needs fixing are my comments in these two files:

• metadata-security.cfg - I pointed out that this file is missing a detailed description. It should have comments at the top that describe the behavior/purpose of these new metadata.visibility.* settings and describe what the values 0, 1 and 2 mean.
• rest.cfg - I pointed out that a lot of the new rest.properties.exposed configs seem to reference settings (in metadata-security.cfg) that don't exist

All my other feedback has been addressed. So, if you can clean up these two very minor things, I think this PR is ready to be merged. Thank you so much!

[tdonohue]

@AdamF42 : Just after submitting my basic approval, I was testing the REST API directly and I found one more minor bug. We need to add a permissions check to the /server/api/core/edititems endpoint as described below. This should also be very quick to fix though!

[tdonohue]

Thanks for the updates today @AdamF42 ! The code now looks good to me, and I'm doing final re-testing now (to verify which outstanding issues need to be moved to separate tickets) before I submit a final approval.

[tdonohue]

👍 Thanks @AdamF42 ! I've finished re-reviewing and testing this today. It's working well for me now, and I've verified that double upload problem (reported on the frontend) is now fixed.

All my other reported issues I'll move to follow-up tickets, as this is mostly working great!

[tdonohue]

@AdamF42 : One other note. Similar to all other CRIS-related PRs, I'm flagging this as "needs documentation" because this PR needs to have documentation added to our DSpace 10.0 docs: https://wiki.lyrasis.org/display/DSDOC10x

Please let me know when you (or one of your colleagues at 4Science) have added the necessary docs, and I'll then remove the label. Thanks again!