The new Edit menu option allows administrators to open a submission form populated with the existing metadata metadata for further enrichment of the item even if an item is archived.

Access to the Functionality

This modality is accessible from the item page.

Along this feature, the possibility to pick which form to use for each collection submission has been introduced:

Edit Modes Configuration

To configure one or more edit modalities for a specific entity type is necessary to add the configuration in the property editModesMap of bean org.dspace.content.edit.service.impl.EditItemModeServiceImpl inside edititem-service.xml file.

The first step is the creation of a new submission-process definition for the entity type in the item-submission.xml file.
For example:

<submission-process name="admin-person-edit">
     <step id="personStep"/>
     <step id="owner" />
     <step id="upload" />
</submission-process>

Once the submission definitions are created you have to add a new entry in the property editModesMap of the bean org.dspace.content.edit.service.impl.EditItemModeServiceImpl.

In an instance without edit modes configuration the property editModesMap is configured as follow:

The editModesMap property is a Map that has as key the entity type name (in lowercase) and (optional) a submission definition, and as value a list of edit modes.

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="person">
                    <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="admin-person-edit" />
                        </bean>
                        <bean class="org.dspace.content.edit.EditItemMode">
                            <property name="name" value="OWNER" />
                            <property name="security">
                                <value type="org.dspace.content.security.CrisSecurity">
                                    OWNER
                                </value>
                            </property>
                            <property name="submissionDefinition" value="person-edit" />
                        </bean>
                    </list>
                </entry>
            </map>
        </property>
    </bean>

As you can see, an edit mode is represented by class org.dspace.content.edit.EditItemMode, this class has follow properties:

• name: this is a unique identifier for the edit mode at entity type level;

• label: this is an optional property, if set, the UI will use its value as i18n key otherwise the UI will use the value of name property;

• submissionDefinition: contains the name of the submission definition to use with the current edit mode (e.g. person-edit or admin-person-edit); Edit lookup logic checks for <entity>.<submission_definition> where <submission_definition> is the submission defined for the collection who the Item to be edited belongs. In case no matches are found, a fallback on the entry with key <entity> is done.

• securities: define the security levels available for the current edit mode and its visibility. It must be set with a list of “security” values.

• security (alternative to “securities”): defines the security level for the current edit mode and its visibility. This property is an Enum (org.dspace.content.edit.EditItemMode) and accepts one of the following values:

  • ADMIN: this value allows only the Administrator to use this edit mode

  • OWNER: this value allows only the item owner to use this edit mode

  • SUBMITTER: this value allows the Submitter of the Item to use this edit mode

  • SUBMITTER_GROUP: this value allows all users in the the group of submitters of the Item owner to use this edit mode

  • CUSTOM: this value is used to define a fine-grained security access. This security level is explained in following paragraph

  • GROUPS: this value is used to define a fine-grained security access to users belonging to a group. This security level is a shortcut for “CUSTOM” value with access policies to be evaluated only according to what defined in “groups” node.

  • ALL: always allowed access, it should be used in pair with custom additional Filter (see in “Additional Filter” paragraph).

Security Levels

Either a single property named security or a list of securities are admitted. This second case applies when the same edit item mode must be made available according to different policies on the item to be edited:

<bean class="org.dspace.content.edit.EditItemMode">
    <property name="name" value="MODE-MANY-SECURITIES" />
    <property name="label" value="edititem.mode.test2" />
    <property name="securities">
      <list>
        <value>
          ADMIN
        </value>
        <value>
          OWNER
        </value>
      </list>
      </property>
    <property name="submissionDefinition" value="edit_admin_publication" />
</bean>

Configure a custom security level

Custom level for user / group

This security level allows to use the edit mode only to the users/groups that are present inside a list of metadata associated to the item. When configuring the CUSTOM security levels you need to set two other properties within the configuration: users and groups. These properties contains a list of metadata used to check if a specific user/group are allowed to use this edit mode

Custom level using metadata

In some cases, you don’t have a direct reference to the owner inside a metadata, and you want to be fine-grained as you could be with the users configuration.

In case you have a referenceable metadata (i.e. dspace.custom-profile) with a mapped dspace.object.owner on itself, you could use the items property inside the EditItemMode configuration.

A valuable example could be the usage of a researcher-profile reference inside a metadata. Usually, the researcher-profile has a reference to its owner (i.e. the user that has claimed the profile) inside the metadata dspace.object.owner. Whenever you want to make editable some items using a metadata-reference to a researcher-profile you can configure the items property with this metadata.

In the previous example we have configured the EditMode for the logged-user that owns the researcher-profile referenced by the my.custom.researcher metadata. So, whenever the logged user matches the dspace.object.owner referenced by the item behind my.custom.researcher, that logged user will be able to edit the item.

Additional Filter

AccessMode Implementing beans (e.g. org.dspace.content.edit.EditItemMode) can be used with an additionalFilter parameter. This parameter represents a bean implementing org.dspace.content.logic.Filter interface. This custom bean is applied in addition to evaluation performed by standard security policies.

For example, in this case:

“FIRST” edit mode would be granted to all users having ADMIN grant (CrisSecurity), and having “John” as first name (AdminNameFilter bean).