DSpace introduces the item edit in submission mode, in addition to the administrative edit functionality.

Access to the Functionality

This modality is accessible from the item details page for the items that have been configured with the dynamic layout of DSpace.
In the item details page, one or more menu entries are shown within the context menu.

The menu entry name shown in the dropdown is configurable with an i18n label on the Angular side. The label key is context-menu.actions.edit-item.btn.<configuration_name>, where <configuration_name> must be replaced with the name of the edit configuration. For more details, read the "Edit Modes Configuration" paragraph.

Edit Modes Configuration

to configure one or more edit modalities for a specific entity type is necessary 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:

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 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.

Below is the detail of the configuration of a specific edit mode:

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:

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 is valorized 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;

• 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).

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

previous configuration are visible only to users that are present in the cris.users metadata and the users that are part of the groups present in cris.groups or dspace.group metadata.

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 cris.custom.researcher metadata. So, whenever the logged user matches the dspace.object.owner referenced by the item behind cris.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).