Page History

...

1. "Select Collection" step: If not already selected, the user must select a collection to deposit the Item into.
2. "Describe" step:  This is where the user may enter descriptive metadata about the Item. This step may consist of one or more pages of metadata entry. By default, there are two pages of metadata-entry. For information on modifying the metadata entry pages, please see Custom Metadata-entry Pages for Submission section below.
3. "Upload" step: This is where the user may upload one or more files to associate with the Item.  For more information on file upload, also see Configuring the File Upload step below.
4. "Review" step: This is where the user may review all previous information entered, and correct anything as needed.
5. "License" step: This is where the user must agree to the repository distribution license in order to complete the deposit.  This repository distribution license is defined in the [dspace]/config/default.license file. It can also be customized per-collection from the Collection Admin UI.  If you are using XMLUI, the default license may be formatted using Simple HTML Fragment Markup.
6. "Complete" step: The deposit is now completed. The Item will either become immediately available or undergo a workflow approval process (depending on the Collection policies).  For more information on the workflow approval process see: Configurable Workflow; for "traditional" workflow see also the section "The Manual DSpace Submission and Workflow System" in Functional Overview.

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.

...

<submission-process>
	    <!--Step 1 will be to Sign off on the License-->
	   <step>
	     <heading>submit.progressbar.license</heading>
	     <processing-class>org.dspace.submit.step.LicenseStep</processing-classing-class>
	     <jspui-binding>org.dspace.app.webui.submit.step.JSPLicenseStep</jspui-binding>
	     <xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.LicenseStep</xmlui-binding>
	     <workflow-editable>false</workflow-editable>
	   </step>
	<!--Step 2 will be to Ask Initial Questions-->
	<step>
	    <heading>submit.progressbar.initial-questions</heading>
	      <processing-class>org.dspace.submit.step.InitialQuestionsStep</process;/processing-class>
	      <jspui-binding>org.dspace.app.webui.submit.step.JSPInitialQuestionsSteonsStep<JSPInitialQuestionsStep</jspui-binding>
	      <xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.InitialQuestionsStep</xmlui-binding>
	      <workflow-editable>true</workflow-editable>
	   </step>
	      ...[other steps]...
</submission-process>

...

<step>
	<heading>submit.progressbar.describe</heading>
	<processing-class>org.dspace.submit.step.DescribeStep</processing-classing-class>
	<jspui-binding>org.dspace.app.webui.submit.step.JSPDescribeStep</jspuilt;/jspui-binding>
	<xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.DescribeStep</xmlui-binding>
	<workflow-editable>true</workflow-editable>
</step>

...

• dc-schema (Required) : Name of metadata schema employed, e.g. dc for Dublin Core. This value must match the value of the schema element defined in dublin-core-types.xml
• dc-element (Required) : Name of the Dublin Core element entered in this field, e.g. contributor.
• dc-qualifier: Qualifier of the Dublin Core element entered in this field, e.g. when the field is contributor.advisor the value of this element would be advisor. Leaving this out means the input is for an unqualified DC element.
• language: If set to true a drop down menu will be shown, containing languages. The selected language will be used as language tag of the metadata field. This feature is currently supported by JSPUI only and only valid for fields of input-type onebox, twobox or textarea. A compulsory argument value-pairs-name must be given containing the name of the value pair that contains all the languages: e.g. <language value-pairs-name="common_iso_languages">true</language>. If the submission configuration contains a language element and the XMLUI is used, no language is stored, even not the default one.
• repeatable: Value is true when multiple values of this field are allowed, false otherwise. When you mark a field repeatable, the UI servlet will add a control to let the user ask for more fields to enter additional values. Intended to be used for arbitrarily-repeating fields such as subject keywords, when it is impossible to know in advance how many input boxes to provide.
• label (Required): Text to display as the label of this field, describing what to enter, e.g. "Your Advisor's Name".
• input-type(Required): Defines the kind of interactive widget to put in the form to collect the Dublin Core value. Content must be one of the following keywords:
  
  • onebox – A single text-entry box.
  • twobox – A pair of simple text-entry boxes, used for repeatable values such as the DC subject item. Note: The 'twobox' input type is rendered the same as a 'onebox' in the XML-UI, but both allow for ease of adding multiple values.
  • textarea – Large block of text that can be entered on multiple lines, e.g. for an abstract.
  • name – Personal name, with separate fields for family name and first name. When saved they are appended in the format 'LastName, FirstName'
  • date – Calendar date. When required, demands that at least the year be entered.
  • series – Series/Report name and number. Separate fields are provided for series name and series number, but they are appended (with a semicolon between) when saved.
  • dropdown – Choose value(s) from a "drop-down" menu list. Note: You must also include a value for the value-pairs-name attribute to specify a list of menu entries from which to choose. Use this to make a choice from a restricted set of options, such as for the language item.
  • qualdrop_value – Enter a "qualified value", which includes both a qualifier from a drop-down menu and a free-text value. Used to enter items like alternate identifiers and codes for a submitted item, e.g. the DC identifier field. Note: As for the dropdown type, you must include the value-pairs-name attribute to specify a menu choice list.
  • list – Choose value(s) from a checkbox or radio button list. If the repeatable attribute is set to true, a list of checkboxes is displayed. If the repeatable attribute is set to false, a list of radio buttons is displayed. Note: You must also include a value for the value-pairs-name attribute to specify a list of values from which to choose.
• hint (Required): Content is the text that will appear as a "hint", or instructions, next to the input fields. Can be left empty, but it must be present.
• required: When this element is included with any content, it marks the field as a required input. If the user tries to leave the page without entering a value for this field, that text is displayed as a warning message. For example, <required>You must enter a title.</required> Note that leaving the required element empty will not mark a field as required, e.g.:<required></required>
• visibility: When this optional element is included with a value, it restricts the visibility of the field to the scope defined by that value. If the element is missing or empty, the field is visible in all scopes. Currently supported scopes are:
  
  • workflow : the field will only be visible in the workflow stages of submission. This is good for hiding difficult fields for users, such as subject classifications, thereby easing the use of the submission system.
  • submit : the field will only be visible in the initial submission, and not in the workflow stages. In addition, you can decide which type of restriction apply: read-only or full hidden the field (default behaviour) using the otherwise attribute of the visibility XML element. For example:<visibility otherwise="readonly">workflow</visibility> Note that it is considered a configuration error to limit a field's scope while also requiring it - an exception will be generated when this combination is detected.
    Look at the example input-forms.xml and experiment with a a trial custom form to learn this specification language thoroughly. It is a very simple way to express the layout of data-entry forms, but the only way to learn all its subtleties is to use it.

...

The following table presents the available keys from the online services, the keys that BTE uses in phase1 and the final output map to DSpace metadata fields.

...