Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

work in progress

Please note that this page describe activities still undergoing. The final solution could differ also a lot from what described here


Before DSpace 7 two main files were used to configure the submission process

  • item-submission.xml
  • input-forms.xml

other than some configurations scatter in the dspace.cfg file.

With the switch to DSpace 7 we have decided to revise the concept behind the submission process, as we want to provide a RESTful application and a single-page UI experience (Angular) we don't want to enforce any more the concept of multi-steps wizard in the submission. For such reason we are replacing "Steps" and "Pages" in the above files with a more abstract concept of section that will be rendered by the UIs build on top of the REST API in unpredictable different ways: as panels in the default proposal for the angular UI, maybe as tabs or subsequent pages in custom UIs.

Moreover, we will try to rationalize the additional configuration migrating them in self-contained files.

The item-submission.xml

The high-level structure is unchanged, the main difference are:

As each page of the old input-forms now is become a different "step" in the item-submission.xml the item-submission.xml file now manage which metadata are avaialble when a submission is done in a specific collection via the submission-map

The input-forms.xml (now submission-forms.xml)

To reflect the big changes in the file structure and purpose we have renamed the file in submission-forms.xml.

At the highest level the changes are:

  • the form-map element is not anymore available, the mapping between collection and sequence of forms is now maintained in a single place the item-submission.xml
  • the form > page element is not anymore available. Each form consist of a single page. As said above pages are grouped together in the item-submission.xml

The value-pairs element now automatically define authorities when the value-pair is referenced by a form > fields > field > input-type without the need to manually register the authority in the dspace.cfg

By default a new form named bitstream-metadata has been introduced. It configures the metadata requested for a bitstream during the submission, see the section about the new access-conditions.xml file below.

The configuration previously in the DSpace.cfg

The following configuration have been moved to the new access-conditions.xml, see the corresponding section

webui.submission.restrictstep.groups see Embargo#Restrictlistofdisplayedgroupstospecific(sub)groups  

webui.submission.restrictstep.enableAdvancedForm

webui.submit.upload.html5

upload.max

webui.submit.upload.required


NEW: The access-conditions.xml

With the PR https://github.com/DSpace/DSpace/pull/1889 a new configuration file will be introduced. It is a spring file: access-conditions.xml that allow to configure the options to present in the upload section. Such configuration is exposed over the new REST API in the /config/submissionuplads endpoint

The xml file has the following structure

  • the uploadConfigurationService map the upload configurations to the section configuration (the section name used in the item-submission.xml file)
  • the uploadConfigurationDefault is an example of configuration where all the existent capabilities of DSpace < 7 are presented. 

Each upload configuration allows to configure which metadata are requested to describe the bitstreams using the name assigned to the specific form configuration in the submission-form.xml. A maxSize and required property can be also configured to specify the limit in bytes for file upload and if at least one file is required or not. This mean that it is now possible to take full advantage of the metadata support at the bitstream level.

Moreover, it defines the list of acceptable policies using the options list property.

An option is defined by the following properties:

  • name: univoquely identify the policy template. It is stored in the resourcepolicy.name once applied
  • groupName or selectGroupName: the first is used to bind the resourcepolicy to a specific group, the later is used to allow the selection of one of the subgroups as principal of the created resourcepolicy. This is the equivalent of the previous Embargo#Restrictlistofdisplayedgroupstospecific(sub)groups configuration option
  • hasStartDate [true|false]. If true the policy to create requires a start date
  • hasEndDate [true|false]. If true the policy to create requires an end date
  • startDateLimit (String). An exact date or a math to apply to the current time to upper limit the start date to use
  • endDateLimit (String). An exact date or a math to apply to the current time to upper limit the end date to use

This new configuration allows to simplify the presentation of pre-set options to the user such as access trough the university network, embargoed, etc. other than offer new opportunities as lease an temporal access.

JIRA Issues & PRs related with these changes

https://github.com/DSpace/DSpace/pull/1852 (merged)

https://github.com/DSpace/Rest7Contract/pull/11 (merged)

https://github.com/DSpace/DSpace/pull/1889

https://github.com/DSpace/Rest7Contract/pull/16

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  • No labels