Page History

...

• The "uploadConfigurationService" bean maps an existing "UploadConfiguration" bean (default is "uploadConfigurationDefault") to a specific step/section name used in item-submission.xml. 

  Code Block
  <!-- 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

  • configurationService (Required through 7.3): reference to the DSpace ConfigurationService (should always be "org.dspace.services.ConfigurationService").  Starting in 7.4 this is no longer required and should not be set.
  • metadata (Required): The metadata "form" to use for this upload configuration. The value specified here MUST correspond to a <form> defined in your submission-forms.xml.  In the below example, the "bitstream-metadata" form is used by the "uploadConfigurationDefault" bean...meaning that form will be used to capture metadata about the uploaded bitstream.
  • options (Required, but can be empty): list of all "AccessConditionOption" beans to enable. This list will be shown to the user to let them select which access restrictions to place on each bitstream. NOTE: To disable the ability to select bitstream access restrictions, comment out all <ref> tags to create an empty list of options.
  • maxSize: Optionally, you can specify a maximum size of file accepted by this UploadConfiguration.  If unspecified, default is to use "upload.max" in dspace.cfg/local.cfg, or have no maximum.

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

    Code Block

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

    
    

• Any number of "AccessConditionOption" beans may be added for applying different types of access permissions to uploaded files (based on which one the user selects). These beans are easy to add/update, and just require the following
  • id (Required): Each defined bean MUST have a unique "id" and have "class=org.dspace.submit.model.AccessConditionOption".
  • groupName: Optionally, define a specific DSpace Group which this Access Condition relates to.  This group will be saved to the ResourcePolicy when this access condition is applied.
  • name: Give a unique name for this Access Condition.  This name is stored in the ResourcePolicy "name" when this access condition is applied.
  • hasStartDate: If the access condition is time-based, you can decide whether a start date is required. (true = required start date, false = disabled/not required).  This start date will be saved to the ResourcePolicy when this access condition is applied.
  • startDateLimit: If the access condition is time-based, you can optionally set an start date limit (e.g. +36MONTHS). This field is used to set an upper limit to the start date based on the current date.  In other words, a value of "+36MONTHS" means that users cannot set a start date which is more than 3 years from today.  This setting's value uses Solr's Date Math Syntax, and is always based on today (NOW).
  • hasEndDate: If the access condition is time-based, you can enable/disable whether an end date is required. (true = required end date, false = disabled/not required).  This end date will be saved to the ResourcePolicy when this access condition is applied.

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

    Code Block

    <!-- 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, DSpace comes with these out-of-the-box Access Conditions (which you can customize/change based on local requirements)
  • "administrator" - access restricts the bitstream to the Administrator group immediately (after submission completes)
  • "openAccess" - makes the bitstream immediately accessible to Anonymous group (after submission completes)
  • "embargoed" - embargoes the bitstream for a period of time (maximum of 3 years, as defined in startDateLimit default setting), after which it becomes anonymously accessible. See also Embargo for discussion of how embargoes work in DSpace.
  • "lease" - makes the bitstream anonymously accessible immediately (after submission completes), but that access expires after a period of time (maximum of 6 months, as defined in endDateLimit default setting). After that date it is no longer accessible (except to Administrators)

...