This page explains various customization and configuration options that are available within DSpace for the Item Submission user interface.
The name and structure of the Submission configuration files changed in 7.x. The DSpace 6.x (and below) "item-submission.xml" and "input-forms.xml" configuration files are no longer supported. In 7.x and above, the format of the "item-submission.xml" file has been updated, and the older "input-forms.xml" has been replaced by a new "submission-forms.xml". You can choose to either start fresh with the new v7 configuration files (see documentation below) and/or use the "./dspace submission-forms-migrate" script to migrate your old configurations into new ones. See the Upgrading DSpace guide (step on "Update your DSpace Configurations") for more information on using the migration script. |
The DSpace Submission process consists of a series of "steps", where each "step" corresponds to one or "sections" in the Submission UI. By default, the DSpace Submission process includes the following steps/sections, in this order:
[dspace]/config/default.license file. It can also be customized per-collection from the Collection Edit UI.To modify or reorganize these submission steps, just modify the [dspace]/config/item-submission.xml file. Please see the section below on Reordering/Removing/Adding Submission Steps.
You can also choose to have different submission processes for different DSpace Collections. For more details, please see the section below on Assigning a custom Submission Process to a Collection.
DSpace also ships with several optional steps which you may choose to enable if you wish. In no particular order:
To enable any of these optional submission steps, just uncomment the step definition within the [dspace]/config/item-submission.xml file. Please see the section below on Reordering/Removing/Adding Submission Steps.
You can also choose to enable certain steps only for specific DSpace Collections. For more details, please see the section below on Assigning a custom Submission Process to a Collection.
The [dspace]/config/item-submission.xml contains the submission configurations for the DSpace UI. This configuration file contains detailed documentation within the file itself, which should help you better understand how to best utilize it.
As of DSpace 7, the following structural changes were made to item-submission.xml:
|
Because this file is in XML format, you should be familiar with XML before editing this file. By default, this file contains the "traditional" Item Submission Process for DSpace, which consists of the following Steps (in this order):
Select Collection -> Describe (two steps) -> Upload -> License -> Complete
If you would like to customize the steps used or the ordering of the steps, you can do so within the <submission-definition> section of the item-submission.xml .
In addition, you may also specify different Submission Processes for different DSpace Collections. This can be done in the <submission-map> section. The item-submission.xml file itself documents the syntax required to perform these configuration changes.
This section describes how Steps of the Submission Process are defined within the item-submission.xml.
The <step-definition> always appear within the <step-definitions> section of the item-submission.xml configuration file.
For example:
<step-definitions> <step-definition id="custom-step"> ... </step> ... </step-definitions> |
The ordering of the <step> tags within a <submission-process> definition directly corresponds to the order in which those steps will appear!
For example, the following defines a Submission Process where the License step directly precedes the Describe step (more information about the structure of the information under each <step> tag can be found in the section on Structure of the <step> Definition below):
<submission-process>
<!--Step 1 will be to Sign off on the License-->
<step id="license"/>
<!--Step 2 & 3 will be to ask for metadata-->
<step id="traditionalpageone"/>
<step id="traditionalpagetwo"/>
...[other steps]...
</submission-process> |
The structure of the <step-definition> tag is as follows:
<step-definition id="traditionalpageone" mandatory="true">
<heading>submit.progressbar.describe.stepone</heading>
<processing-class>org.dspace.app.rest.submit.step.DescribeStep</processing-class>
<type>submission-form</type>
<!-- <scope visibility="hidden" visibilityOutside="hidden">submission</scope> -->
</step-definition> |
Each step contains the following elements/attributes. The required elements are so marked:
org.dspace.submit.AbstractProcessingStep class (or alternatively, extend one of the pre-existing step processing classes in org.dspace.submit.step.*)<form> defined in the submission-forms.xml configuration file. In this situation, the <step-definition> "id" attribute MUST map to a <form> "name" attribute defined in submission-forms.xml. Any value is allowed, and only "submission-form" has a special meaning at this time.The removal of existing steps and reordering of existing steps is a relatively easy process!
Reordering steps
<submission-process> tag which defines the Submission Process that you are using. If you are unsure which Submission Process you are using, it's likely the one with name="traditional", since this is the traditional DSpace submission process.<step> tags within that <submission-process> tag. Be sure to move the entire <step> tag.Removing one or more steps
<submission-process> tag which defines the Submission Process that you are using. If you are unsure which Submission Process you are using, it's likely the one with name="traditional", since this is the traditional DSpace submission process.<! -- and -->) the <step> tags which you want to remove from that <submission-process> tag. Be sure to comment out the entire <step > tag.Adding one or more optional steps
<submission-process> tag which defines the Submission Process that you are using. If you are unsure which Submission Process you are using, it's likely the one with name="traditional", since this is the traditional DSpace submission process.<! -- and -->) the <step> tag(s) which you want to add to that <submission-process> tag. Be sure to uncomment the entire <step> tag.Assigning a custom submission process to a Collection in DSpace involves working with the submission-map section of the item-submission.xml. For a review of the structure of the item-submission.xml see the section above on Understanding the Submission Configuration File.
Each name-map element within submission-map associates a collection with the name of a submission definition.
There are two ways to configure this mapping:
For example, the following fragment shows how the collection with handle "12345.6789/42" is assigned the "custom" submission process:
<submission-map>
<name-map collection-handle="12345.6789/42" submission-name="custom" />
...
</submission-map>
<submission-definitions>
<submission-process name="custom">
...
</submission-definitions>
|
For example, the following fragment shows how to map all Collections which use the out-of-the-box Entity Types to a submission definition of the same name:
<submission-map>
...
<name-map collection-entity-type="Publication" submission-name="Publication"/>
<name-map collection-entity-type="Person" submission-name="Person"/>
<name-map collection-entity-type="Project" submission-name="Project"/>
<name-map collection-entity-type="OrgUnit" submission-name="OrgUnit"/>
<name-map collection-entity-type="Journal" submission-name="Journal"/>
<name-map collection-entity-type="JournalVolume" submission-name="JournalVolume"/>
<name-map collection-entity-type="JournalIssue" submission-name="JournalIssue"/>
...
<submission-map> |
It's a good idea to keep the definition of the default name-map, so there is always a default for collections which do not have a custom form set.
You will need the handle of a collection in order to assign it a custom form set. To discover the handle, go to the Community or Collection in the DSpace UI. Look for the "Permanent URI" listed near the top of the page. It should look something like:
http://myhost.my.edu/handle/12345.6789/42 |
The handle is everything after "handle/" (in the above example it is "12345.6789/42"). It should look familiar to any DSpace administrator. That is what goes in the collection-handle attribute of your name-map element.
Alternatively to a collection's Handle, Entities Types can be used as an attribute. With these configurations you will enable default submission forms per Entity type. You don't have to specify every collection's handle to use for a particular submission form if you intend to use entities.
In order to do it so, instead of collection-handle attribute you need to use collection-entity-type. The possible values for this attribute are the ones that you use or that you specified in relationship-types.xml file (please check the documentation for more information). In order the submission process to be assigned to an entity type, you need to previously have associated an Entity Type to a Collection (please check: Configurable Entities#3.ConfigureCollectionsforeachEntitytype).
As an example, for every time you need to insert a new person in a Person's collection. You just need to specify the submission form to be used, like: submission-name="customPerson" in the example and also the entity type that is associated, like collection-entity-type="Person".
<submission-map>
<name-map collection-entity-type="Person" submission-name="customPerson" />
...
</submission-map>
<submission-definitions>
<submission-process name="customPerson">
...
</submission-definitions>
|
If a collection collection-handle="12345.6789/42" configuration will prevail over this configuration. Meaning that if a collection-entity-type is defined and a collection-handle is also defined and if a collection handle overlaps in both configurations, then, the submission to be considered it will be the one that is defined by collection-handle (it will prevail the one with more granularity).
This section explains how to customize the Web forms used by submitters and editors to enter and modify the metadata for a new item. These metadata web forms are controlled by the Describe step within the Submission Process. However, they are also configurable via their own XML configuration file [dspace]/config/submission-forms.xml.
In this configuration you can create alternate metadata forms, which can then be mapped to a "submission-form" step in the "item-submission.xml" (see above).
In creating custom metadata forms, you can choose:
All of the custom metadata-entry forms for a DSpace instance are controlled by a single XML file, submission-forms.xml, in the config subdirectory under the DSpace home, [dspace]/config/submission-forms.xml. DSpace comes with a number of sample forms which implement the traditional metadata-entry forms, and also serves as a well-documented example. Some default forms include:
The rest of this section explains how to create your own sets of custom forms.
The description of a set of fields through which submitters enter their metadata is called a form (in the UI, each "form" is displayed in a separate collapsible section). A form is identified by a unique symbolic name. In the XML structure, the form is broken down into rows of fields. This allows you to place smaller fields side-by-side in a single, horizontal row, or alternatively decide to display one field per row.
As of DSpace 7, the following structural changes were made to this configuration:
|
The XML configuration file has a single top-level element, input-forms, which contains two elements in a specific order. The outline is as follows:
<input-forms>
<-- Form Set Definitions -->
<form-definitions>
<form name="traditionalpageone">
...
</form>
...
</form-definitions>
<-- Name/Value Pairs used within Multiple Choice Widgets -->
<form-value-pairs>
<value-pairs value-pairs-name="common_iso_languages" dc-term="language_iso">
...
</value-pairs>
...
</form-value-pairs>
</input-forms>
|
Keep in mind, the "submission-forms.xml" only defines forms and value-pairs (used for specific fields like selectboxes). To enable a form requires also updating the "item-submission.xml" configuration to use that form (see also above):
So, if you modify submission-forms.xml, you may need to double check your changes will be used in your item-submission.xml.
You can add a new form by creating a new form element within the form-definitions element. It has one attribute, name, which as described above must match the "id" of a <step-definition> in "item-submission.xml".
The content of the form is a sequence of row elements. Each of these corresponds to a single, horizontal row, containing metadata input fields. The rows are presented in sequence, with the first row displayed at the top of the form. A form is displayed as a section (or step) within the submission process.
A form may contain any number of rows. A row generally only contains one or two input fields (including more than one input field may require the "style" setting, see below). Each field defines an interactive dialog where the submitter enters one of the Dublin Core metadata items.
Each field contains the following elements, in the order indicated. The required sub-elements are so marked:
<language value-pairs-name="common_iso_languages">true</language>. [dspace]/config/controlled-vocabularies/[name].xml. This setting may be used to provide auto-complete functionality, for example in the "Subject Keywords" field (which uses the "tag" input type). See also the "Configuring Controlled Vocabularies" section below.error.validation.pattern.schema_element_qualifier and the schema, element and qualifier of the field. For example: "error.validation.pattern.dc_identifier": "The identifier can only consist of numbers". For instructions on how to add custom entries see: Customize UI labels using Internationalization (i18n) filesA field configured to be visible only with submission scope, while is hidden with workflow scope
<field>
<dc-schema>dc</dc-schema>
<dc-element>title</dc-element>
<dc-qualifier>alternative</dc-qualifier>
<repeatable>true</repeatable>
<label>Other Titles</label>
<input-type>onebox</input-type>
<hint>If the item has any alternative titles, please enter them here.</hint>
<required></required>
<visibility>submission</visibility>
</field> |
A field configured to be visible only with workflow scope, while is read-only with submission scope
<field>
<dc-schema>dc</dc-schema>
<dc-element>title</dc-element>
<dc-qualifier>alternative</dc-qualifier>
<repeatable>true</repeatable>
<label>Other Titles</label>
<input-type>onebox</input-type>
<hint>If the item has any alternative titles, please enter them here.</hint>
<required></required>
<readonly>readonly</readonly>
<visibility>workflow</visibility>
</field> |
Available in 7.3 and later |
A field can be made visible depending on the value of dc.type. A new field element, <type-bind>, has been introduced to facilitate this. The <type-bind> takes a comma separated list of publication types. If the field is missing or empty, it will always be visible. In this example the field will only be visible if a value of "thesis" or "ebook" has been entered into dc.type on an earlier page:
<field>
<dc-schema>dc</dc-schema>
<dc-element>identifier</dc-element>
<dc-qualifier>isbn</dc-qualifier>
<label>ISBN</label>
<type-bind>thesis,ebook</type-bind>
</field> |
A field may be configured multiple times in the submission configuration with different values in type-bind. This is useful if a field is required for one type but not another, or should display a different label and hint message depending on the publication type:
<field>
<dc-schema>dc</dc-schema>
<dc-element>identifier</dc-element>
<dc-qualifier>isbn</dc-qualifier>
<label>ISBN</label>
<type-bind>book,ebook</type-bind>
<required>You must enter an ISBN for this book</required>
</field>
<field>
<dc-schema>dc</dc-schema>
<dc-element>identifier</dc-element>
<dc-qualifier>isbn</dc-qualifier>
<label>ISBN of Parent Publication</label>
<type-bind>thesis,book chapter,letter</type-bind>
<hint>Enter the ISBN of the book in which this was published</hint>
</field> |
If a field is required but is bound to a type that does not match the submitted publication, the required value will be ignored.
Note: When the submitter changes the Type field, other fields (usually just below it) dynamically appear. There's a brief demo of this feature in the 2022-07-13 - DSpace 7 Q&A webinar at time 19:05. The submission process is one page, but it has collapsible sections, each of which corresponds to one of the old "pages".
DSpace supports controlled vocabularies to confine the set of keywords that users can use while describing items. The need for a limited set of keywords is important since it eliminates the ambiguity of a free description system, consequently simplifying the task of finding specific items of information. The controlled vocabulary allows the user to choose from a defined set of keywords organized in an tree (taxonomy) and then use these keywords to describe items while they are being submitted.
The taxonomies are described in XML following this (very simple) structure:
<node id="acmccs98" label="ACMCCS98">
<isComposedBy>
<node id="A." label="General Literature">
<isComposedBy>
<node id="A.0" label="GENERAL"/>
<node id="A.1" label="INTRODUCTORY AND SURVEY"/>
...
</isComposedBy>
</node>
...
</isComposedBy>
</node> |
You are free to use any application you want to create your controlled vocabularies. A simple text editor should be enough for small projects. Bigger projects will require more complex tools. You may use Protegé to create your taxonomies, save them as OWL and then use a XML Stylesheet (XSLT) to transform your documents to the appropriate format. Future enhancements to this add-on should make it compatible with standard schemas such as OWL or RDF.
New vocabularies should be placed in [dspace]/config/controlled-vocabularies/ and must be according to the structure described.
Vocabularies need to be associated with the corresponding metadata fields. Edit the file [dspace]/config/submission-forms.xml and place a "vocabulary" tag under the "field" element that you want to control. Set value of the "vocabulary" element to the name of the file that contains the vocabulary, leaving out the extension (the add-on will only load files with extension "*.xml"). For example:
<field>
<dc-schema>dc</dc-schema>
<dc-element>subject</dc-element>
<dc-qualifier></dc-qualifier>
<repeatable>true</repeatable>
<label>Subject Keywords</label>
<input-type>onebox</input-type>
<hint>Enter appropriate subject keywords or phrases below.</hint>
<required></required>
<vocabulary>srsc</vocabulary>
</field> |
The vocabulary element has an optional boolean attribute closed that can be used to force input only with the Javascript of controlled-vocabulary add-on. The default behaviour (i.e. without this attribute) is as set closed="false". This allow the user also to enter the value in free way.
Controlled vocabularies have two main display types in the submission form:
<input-type>onebox</input-type> will display a onebox style field (optionally repeatable) which pops up the entire hierarchical vocabulary to allow you to select an individual term.
<input-type>tag</input-type> will display a tag-style field (optionally repeatable) which suggests terms within the vocabulary as you type.
The following vocabularies are currently available by default:
Finally, your custom form description needs to define the "value pairs" for any fields with input types that refer to them. Do this by adding a value-pairs element to the contents of form-value-pairs. It has the following required attributes:
Each value-pairs element contains a sequence of pair sub-elements, each of which in turn contains two elements:
Here is a menu of types of common identifiers:
<value-pairs value-pairs-name="common_identifiers" dc-term="identifier">
<pair>
<displayed-value>Gov't Doc #</displayed-value>
<stored-value>govdoc</stored-value>
</pair>
<pair>
<displayed-value>URI</displayed-value>
<stored-value>uri</stored-value>
</pair>
<pair>
<displayed-value>ISBN</displayed-value>
<stored-value>isbn</stored-value>
</pair>
</value-pairs>
|
It generates the following HTML, which results in the menu widget below. (Note that there is no way to indicate a default choice in the custom input XML, so it cannot generate the HTML SELECTED attribute to mark one of the options as a pre-selected default.)
<select name="identifier_qualifier_0">
<option VALUE="govdoc">Gov't Doc #</option>
<option VALUE="uri">URI</option>
<option VALUE="isbn">ISBN</option>
</select>
|
The DSpace web application only reads your custom form definitions when it starts up, so it is important to remember:
Any mistake in the syntax or semantics of the form definitions, such as poorly formed XML or a reference to a nonexistent field name, may result in errors in the DSpace REST API & UI. The exception message (at the top of the stack trace in the dspace.log file) usually has a concise and helpful explanation of what went wrong. Don't forget to stop and restart the servlet container before testing your fix to a bug.
The Upload step in the DSpace submission process has a few configuration options which can be set with your [dspace]/config/local.cfg configuration file. They are as follows:
After uploading a file (bitstream) in the Submission UI, you can optionally edit that bitstream's metadata. The form displayed on that edit screen is built by the "bitstream-metadata" form defined in submission-forms.xml. You can modify that form to change the fields captured for a Bitstream. However, the "dc.title" field is REQUIRED in order to store the name of the file.
<form-definitions>
<!-- Form used for entering in Bitstream/File metadata after uploading a file -->
<form name="bitstream-metadata">
...
</form>
</form-definitions> |
After uploading a file (bitstream) in the Submission UI, you can optionally edit that bitstream's access conditions. This allows you to embargo a bitstream, lease it, or limit it to Administrators only.
These access conditions are defined in a new Spring Bean configuration file [dspace]/config/spring/api/access-conditions.xml
The "uploadConfigurationService" bean maps an existing "UploadConfiguration" bean (default is "uploadConfigurationDefault") to a specific step/section name used in item-submission.xml.
<!-- This default configuration says the <step-definition id="upload"> defined in item-submission.xml uses "uploadConfigurationDefault" -->
<bean id="uploadConfigurationService" class="org.dspace.submit.model.UploadConfigurationService">
<property name="map">
<map>
<entry key="upload" value-ref="uploadConfigurationDefault" />
</map>
</property>
</bean> |
One or more UploadConfiguration beans may exist, providing different options for different upload sections. An "UploadConfiguration" consists of several properties:
name (Required): The unique name of this upload configuration
required: Optionally, you can specify if a file upload is required for this UploadConfiguration. If true, upload is required and users cannot complete a submission without uploading at least one file. If false, no upload is required to complete the submission. If unspecified, default is to use "webui.submit.upload.required" configuration in dspace.cfg/local.cfg, which defaults to "true" (file upload required).
<bean id="uploadConfigurationDefault" class="org.dspace.submit.model.UploadConfiguration">
<property name="name" value="upload"></property>
<property name="configurationService" ref="org.dspace.services.ConfigurationService"/>
<property name="metadata" value="bitstream-metadata" />
<property name="options">
<!-- This is the list of access options which will be displayed on the "bitstream-metadata" form -->
<!-- If no <ref> tags appear in this list, then access restrictions will not be allowed on bitstreams -->
<list>
<ref bean="openAccess"/>
<ref bean="lease"/>
<ref bean="embargoed" />
<ref bean="administrator"/>
</list>
</property>
</bean> |
endDateLimit: If the access condition is time-based, you can optionally set an end date limit (e.g. +6MONTHS). This field is used to set an upper limit to the start date based on the current date. In other words, a value of "+6MONTHS" means that users cannot set an end date which is more than 6 months from today. This setting's value use Solr's Date Math Syntax, and is always based on today (NOW).
<!-- Example access option named "embargo", which lets users specify a future date
(not more than 3 years from now) when this file will be available to Anonymous users -->
<bean id="embargoed" class="org.dspace.submit.model.AccessConditionOption">
<property name="groupName" value="Anonymous"/>
<property name="name" value="embargo"/>
<property name="hasStartDate" value="true"/>
<property name="startDateLimit" value="+36MONTHS"/>
<property name="hasEndDate" value="false"/>
</bean> |
By default, the "Item Access Conditions" step is disabled. To enable it, simply update your item-submission.xml to include this tag in your <submission-process>:
<submission-process name="traditional"> ... <!-- This step enables embargoes and other access restrictions at the Item level --> <step id="itemAccessConditions"/> </submission-process> |
After making this update, you will need to restart your backend (REST API) for the changes to take effect.
The "Item Access Conditions" step uses a similar access condition configuration as the "Upload" step as described in the Modifying access conditions (embargo, etc.) presented for Bitstreams documentation above.
All available Item access conditions are defined in a new Spring Bean configuration file [dspace]/config/spring/api/access-conditions.xml
One or more "AcccessConditionConfiguration" beans may exist, providing different options for different submission forms (only one should be in use in a form at a time). By default an "accessConditionConfigurationDefault" bean is defined. An "AccessConditionConfiguration" consists of several properties:
name (Required): The unique name of this configuration. It must match the "id" of the step defined in your item-submission.xml
canChangeDiscoverable: Whether this configuration allows users to change the discoverability of an Item. A "discoverable" item is one that is findable through all search/browse interfaces, provided that you have access to see that Item. A "non-discoverable" item is one that will never be findable through search/browse (except by Administrators)... instead a direct link is necessary to view the Item. See also DSpace Item State Definitions. When "canChangeDiscoverable" is "true", the user can modify discoverability in this submission section. When set to "false", the user cannot modify this setting and all submitted Items will be "discoverable".
What happens when a User selects different access conditions for an Item (via the "Item Access Conditions" step) and its files (via the "Upload" step)? Generally speaking, both
Generally speaking, both access restrictions will be applied. Here's some examples:
By default, the "Sherpa RoMEO Policy" step is disabled. To enable it, simply update your item-submission.xml to include this tag in your <submission-process>:
<submission-process name="traditional"> ... <!-- This step shows when appropriate publisher policies retrieved from SHERPA/RoMEO --> <step id="sherpaPolicies"/> </submission-process> |
you must also obtain your sherpa.romeo.apikey registering you client application here https://v2.sherpa.ac.uk/api/ and put them in the local.cfg
sherpa.romeo.apikey = <YOUR-API-KEY> |
The step needs to extract the ISSN of the Journal where the publication has been submitted/published to query the Sherpa/RoMEO database in order to visualize the publisher policies, this is done by an implementation of the org.dspace.app.sherpa.submit.ISSNItemExtractor interface configured in the org.dspace.app.sherpa.submit.SHERPASubmitConfigurationService
The configuration is provided by Spring config/spring/api/sherpa.xml
<bean class="org.dspace.app.sherpa.submit.SHERPASubmitConfigurationService" id="org.dspace.app.sherpa.submit.SHERPASubmitConfigurationService"> <property name="issnItemExtractors"> <list> <bean class="org.dspace.app.sherpa.submit.MetadataValueISSNExtractor"> <property name="metadataList"> <list> <value>dc.identifier.issn</value> </list> </property> </bean> <!-- Uncomment this bean if you have SHERPARoMEOJournalTitle enabled <bean class="org.dspace.app.sherpa.submit.MetadataAuthorityISSNExtractor"> <property name="metadataList"> <list> <value>dc.title.alternative</value> </list> </property> </bean> --> </list> </property> </bean> |
out-of-box implementations able to extract the ISSN from the metadata value or authority are provided.
By default, the "Identifiers" step is disabled. To enable it, update your item-submission.xml to include this tag in your <submission-process>:
<submission-process name="traditional">
...
<!-- This step shows identifiers already registered for this in-progress item →
<step id="identifiers"/>
...
</submission-process>
It is recommended to display this step above most others so that the submitter can clearly see any identifiers that will be created while completing their submission.
You must also enable registration of identifiers for workspace and workflow items in dspace/config/modules/identifiers.cfg or local.cfg (this is disabled by default):
identifiers.submission.register = true
While editing this configuration, pay attention to the filter configuration - logical item filters can be referenced here to apply some conditions as to whether an item qualifies for a DOI or not (eg. based on metadata entered, the type of work, or so on).
Any identifiers registered for the current submission or workflow item will be displayed in a read-only section. If no identifiers are registered, a placeholder “no identifiers” message will be displayed.
If DOI registration is configured for logical item filtering, the DOI will be minted (in a 'pending' state) or deleted as appropriate whenever the in-progress item is saved, depending on whether it passes the filter test.
See dspace/config/modules/identifiers.cfg
First, a brief warning: Creating a new Submission Step requires some Java knowledge, and is therefore recommended to be undertaken by a Java programmer whenever possible.
In most scenarios, this is NOT necessary, as it's much easier to configure a custom Submission Step using DescribeStep or similar.
That being said, at a higher level, creating a new Submission Step requires the following (in this relative order):
org.dspace.submit.AbstractProcessingStep class and implement all methods defined by that abstract class.item-submission.xml configuration file.item-submission.xml, see the section above on Defining Steps (<step>) within the item-submission.xml.