Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.



Please note that as the consumer was initially developed to deal with the import of bibliographic information of the authors from ORCID it was named crisorcid but it now manage all kind of object (rp, orgunit, project, 2nd level entities su as journal, etc.) and metadata


when an item is archived the consumer looks to the item metadata that are using an authority implementing the interface and so potentially linked to CRIS objects. For each metadata values that doesn't have an authority key or that have a temporary authority (one that starts with "will be generated::") the consumer create a new CRIS object of the proper type (rp, orgunit, ...) setting the name of the created instance to the text value of the original metadata. The type of the new CRIS object to create is provided by the Authority implementation associated with the specific metadata, so for instance


  • it is possible to set the visibility of the created property to private (0) or public (1)
  • it is possible to manage repeatable metadata such as authors using the useAll flag. False mean that the filler expects to have exactly the same number of primary metadata ( in our example) than additional metadata (custom.contributor.affiliation) and use the additional metadata to fill the researcher profile created by the primary metadata with the same place. The first custom.contributor.affiliation is added to the first, etc.


    The submission understand such configuration and react adding more box to input the additional metadata any time that a new value for the primary metadata is added. Currently the user experience is not optimal as the primary value and the additional metadata are NOT placed aside and there are no extra validation that assure a proper use of the UI (the user could input three author names but only two affiliation, etc.).

  • The filler works on all the metadata so if the custom.contributor.affiliation is controlled by an OUAuthority and the value is not selected from the existing OrgUnits list a new OU object can be created and filled with this infrastructure.

The automatic creation of entities as part of a DSpace item submission is managed by the configuration at cris.cfg, both at a global and at single metadata level. Global configuration is configured through import.submission.enabled.entity key. Specific metadata fields configuration is done with import.submission.enabled.entity.<schema>.<element>.<qualifier> key. For instance:



Code Block
import.submission.enabled.entity = true = false

will mean that dspace-cris will create new cris objects as usual (i.e. journals, projects, etc.), with the exception of new authors at metadata field.