Page History

...

Each step contains the following elements/attributes. The required elements are so marked:

• mandatory (attribute): [true|false] When true, the step's section is displayed by default to all users in the UI.  When false, the step is not displayed and must be activated explicitly by the user by selecting it in the UI or supplying data of interest to the section.
• heading: Partial I18N key (defined in the UI's language packs) which corresponds to the text that should be displayed in section header for this step. This partial I18N key is prefixed with "submission.sections.".  Therefore, the full i18n key is "submission.sections.[heading]" in the User Interface's language packs (e.g. en.json5 for English)
• processing-class (Required): Full Java path to the Processing Class for this Step. This Processing Class must perform the primary processing of any information gathered in this step. All valid step processing classes must extend the abstract org.dspace.submit.AbstractProcessingStep class (or alternatively, extend one of the pre-existing step processing classes in org.dspace.submit.step.*)
• type :
• scope:
• workflow-editable (replaced by scope): Defines whether or not this step can be edited during the Edit Metadata process with the DSpace approval/rejection workflow process. Possible values include true and false. If undefined, defaults to true (which means that workflow reviewers would be allowed to edit information gathered during that step).

Reordering/Removing/Adding Submission Steps

The removal of existing steps and reordering of existing steps is a relatively easy process!

Reordering steps

1. Locate the <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.
2. Reorder the <step> tags within that <submission-process> tag. Be sure to move the entire <step> tag (i.e. everything between and including the opening <step> and closing </step> tags).
   • Hint #1: The <step> defining the Review/Verify step only allows the user to review information from steps which appear before it. So, it's likely you'd want this to appear as one of your last few steps
   • Hint #2: If you are using it, the <step> defining the Initial Questions step should always appear before the Upload or Describe steps since it asks questions which help to set up those later steps.

• (Required): The type of step defined. Most steps are of type "submission-form", which means they directly map to a <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.
• scope: Optionally, allows you to limit the "scope" of this particular step, and define whether the step is visible outside that scope.  Valid scope values include "submission" (limited to the submission form) and "workflow" (limited to workflow approval process). You can also define a "visibilityOutside" attribute which can be set to "read-only" (in other scopes you can see this step but not edit it), or "hidden" (in other scopes you cannot see this step).

Reordering/Removing/Adding Submission Steps

The removal of existing steps and reordering of existing steps is a relatively easy process!

Reordering steps

1. Locate the <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.
2. Reorder the <step> tags within that <submission-process> tag. Be sure to move the entire <step> tag.

Removing one or more steps

1. Locate the <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.
2. Comment out (i.e. surround with <! -- and -->) the <step> tags which you want to remove from that <submission-process> tag. Be sure to comment out the entire <step > tag.
   • Hint: You cannot remove the "collection" step, as an DSpace Item cannot exist without belonging to a Collection.

Adding one or more optional Removing one or more steps

1. Locate the <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.
2. Comment out Uncomment (i.e. surround with remove the <! -- and -->) the <step> tags tag(s) which you want to add to remove from that <submission-process> tag. Be sure to comment out uncomment the entire <step > tag (i.e. everything between and including the opening <step> and closing </step> tags).
   • Hint #1: You cannot remove the Select a Collection step, as an DSpace Item cannot exist without belonging to a Collection.
   • Hint #2: If you decide to remove the <step> defining the Initial Questions step, you should be aware that this may affect your Describe and Upload steps! The Initial Questions step asks questions which help to initialize these later steps. If you decide to remove the Initial Questions step you may wish to create a custom, automated step which will provide default answers for the questions asked!

Adding one or more optional steps

1. Locate the <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.
2. Uncomment (i.e. remove the <! -- and -->) the <step> tag(s) which you want to add to that <submission-process> tag. Be sure to uncomment the entire <step> tag (i.e. everything between and including the opening <step> and closing </step> tags).

Assigning a custom Submission Process to a Collection

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. Its collection-handle attribute is the Handle of the collection. Its submission-name attribute is the submission definition name, which must match the name attribute of a submission-process element (in the submission-definitions section of item-submission.xml.

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>

It's a good idea to keep the definition of the default name-map from the example input-forms.xml so there is always a default for collections which do not have a custom form set.

Getting A Collection's Handle

You will need the handle of a collection in order to assign it a custom form set. To discover the handle, go to the "Communities & Collections" page under "Browse" in the left-hand menu on your DSpace home page. Then, find the link to your collection. It should look something like:

http://myhost.my.edu/dspace/handle/12345.6789/42

The underlined part of the URL is the handle. It should look familiar to any DSpace administrator. That is what goes in the collection-handle attribute of your name-map element.

Custom Metadata-entry Pages for Submission

Introduction

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/input-forms.xml).

You can customize the "default" metadata forms used by all collections, and also create alternate sets of metadata forms and assign them to specific collections. In creating custom metadata forms, you can choose:

• The number of metadata-entry pages.
• Which fields appear on each page, and their sequence.
• Labels, prompts, and other text associated with each field.
• List of available choices for each menu-driven field.

NOTE: The cosmetic and ergonomic details of metadata entry fields remain the same as the fixed metadata pages in previous DSpace releases, and can only be altered by modifying the appropriate stylesheet and JSP pages.

1. <step> tag.

Assigning a custom Submission Process to a Collection

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. Its collection-handle attribute is the Handle of the collection. Its submission-name attribute is the submission definition name, which must match the name attribute of a submission-process element (in the submission-definitions section of item-submission.xml.

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>

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.

Getting A Collection's Handle

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.

Custom Metadata-entry Steps for Submission

Introduction

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:

• Which fields appear on each form, and their sequence.  (Keep in mind, each "form" represents to a "step" or section)
• Labels, prompts, and other text associated with each field.
• Ability to display smaller fields side-by-side in a single "row"
• List of available choices for each menu-driven field.

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:

• "bitstream-metadata" - This is a special form which defines the metadata fields available for every uploaded bitstream (file) 
• "traditionalpageone" - A sample form which is used by the first "Describe" step defined in item-submission.xml
• "traditionalpagetwo" - A sample form which is used by the second "Describe" step defined in item-submission.xml
• A number of sample forms for various out-of-the-box Configurable Entities.  These forms all have a corresponding <step> defined in item-submission.xml.  In conjunction to those <step> definitions, these forms may be used to submit new Entities of specific types. Usually this is done by mapping that Entity-specific submission-process (in item-submission.xml) to a Collection which is used for new submissions of that Entity.

All of the custom metadata-entry forms for a DSpace instance are controlled by a single XML file, input-forms.xml, in the config subdirectory under the DSpace home, [dspace]/config/input-forms.xml. DSpace comes with a sample configuration that implements the traditional metadata-entry forms, which also serves as a well-documented example. The rest of this section explains how to create your own sets of custom forms.

DSpace Custom Submission Form Template.ods is a workbook to facilitate creating custom submission forms. The information below is summarized in columns. The "traditional form fields" sheet lists the default submission fields. The "custom form fields" sheet can be used to facilitate creating a custom submission form. See the "notes" sheet for more detail.

Describing Custom Metadata Forms (NEEDS UPDATING)

The description of a set of pages through which submitters enter their metadata is called a form (although it is actually a set of forms, in the HTML sense of the term). A form is identified by a unique symbolic name. In the XML structure, the form is broken down into a series of pages: each of these represents a separate Web page for collecting metadata elements.

...