Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Small edits to smooth the language; no changes in function

...

Warning
titlework in progress

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


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

...

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 built on top of the REST API in various ways: as panels in the default proposal for the angular UI, or maybe as tabs or subsequent pages in custom UIs.

...

  • the form-map element is not anymore available.  The mapping between collection and sequence of forms is now maintained in a single place:  config/item-submission.xml.
  • the form > page element is not anymore available.  Each form consists of a single page. As said above, pages are grouped together in the config/item-submission.xml.
  • a new children child mandatory element row has been introduced in the form-definitions to allow to put more fields in a single row. The layout of the row is automatically defined by the number of fields in the row (i.e. 2 fields will mean a "col-6" bootstrap style) but can be customized using the new style element in the field tag.

The value-pairs element now automatically defines 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.

...

  • name: uniquely 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 latter is used to allow the selection of one of the subgroups in a group 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 date expression to apply to the current time, to set an upper limit on the start date to use.
  • endDateLimit (String). An exact date, or a math date expression to apply to the current time, to set an upper limit on the end date to use.

...

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

...