Versions Compared

Key

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

...


It has been confirmed to us that this feature is part of the Data Quality Module,  which 4Sience is currently working on.  We will therefore participate in the financing of this module (to become Open Source). Help is welcome.

Idea


Who?What?NoteStatus

Status
colourYellow
titleInitiated
Hamburg University of Technology (Oliver Goldschmidt)

Status
colourGreen
titleinterested

Allow multiple Affiliations per person on publication level

In DSpace-CRIS it's possible to set an affiliation for authors or other persons on publication level. But in the current implementation it's only possible to set just one affiliation per author. As far as I know, this is the same as on DSpace-CRIS 7. Does anybody use setting affiliations for persons on publication level and how do you handle that?
-----

Hi Oliver, we are handeling it with further child-fields. Currently we are supporting one further affiliation - in future we want to add 3 more. If anybody has a better idea, we are interested.

Best Dirk. Fraunhofer IRB (Dirk Eisengräber-Pabst)

-----

Hi Oliver, in our settings one person has one affiliation (delivered via LDAP) and can set additional affilations by choice. E.g. https://fis.uni-bamberg.de/cris/rp/rp14224. So you enter the author's name in the submission and receive a preview of the entered affiliations, from which you can select one. That fits our needs.
Best Steffen, University of Bamberg (Steffen Illig )

Status
colourYellow
titleIdea

Status
colourYellow
titleInitiated
Hamburg University of Technology (Oliver Goldschmidt)

Status
colourGreen
titleinterested

Importing items as private with bulk importOn DSpace-CRIS 7 2022.03.01 it's possible to set items as discoverable or not discoverable in the bulk import excel file. But it's not possible to create items, which are really private (no READ permission to Anonymous). For us, this is pretty bad as we are using the bulk import to import persons from our LDAP and need to restrict access to some of them. Does anybody else have the same problem?

Status
colourBlue
titlePlanned (with 4Science)

Status
colourYellowGreen
titleInitiatedinterested
University of Bamberg (Steffen Illig )status
colourGreen
titleinterested

Script Merging Entities

Our use case is: by now we regulary merge Persons (rps), which are created by mistake during the submission or by our ldap. In Dspace-Cris 5.X this could only done by our developers. In DS-CRIS7 CRIS 7 we would like to have a similar function operable via process to enable more colleagues to do this work.

We would like to merge two entities, so that only one entity remains. The remaining one should contain all relationships and metadatafields from the deleted entity without losing its own metadatafields. Additionally the bitstreams, orcid history and subscriptions and other references need to be copied. Some kind of configurable logic should prohibit certain unique metadatafields from being added (e.g. dspace.entity.type, person.identifier.orcid, dspace.object.owner informations etc...) to the remaining entity.

Status
colourYellow
title

Status
colourBlue
titlePlanned (with 4Science)

Status
colourYellow
titleInitiated
Hamburg University of Technology (Oliver Goldschmidt )

Status
colourGreen
titleinterested

See all languages for specific metadata fields (instead of only the values in the language, which is currently chosen on the UI)

If metadata fields with different languages are set (for instance a title in german and a title in english), the german title will only be displayed, when German is chosen as the language of the User interface. For some use cases this is a very nice feature. But for some metadata fields this could be unwanted (for instance if you have subject headings in different languages, you may want to see all of them at once, independently from the actually chosen language).

Status
colourYellow
titleIdea

Status
colourYellow
titleInitiated
Hamburg University of Technology (Oliver Goldschmidt)

Status
colourGreen
titleinterested

No option to pass a user to bulk import via command lineOn command line it is not possible to set a user, who should execute the operation on DSpace end. That is a problem, because it's impossible to create new entities via bulk import on command line as the user needs to be allowed to create new entities to the collection the import is targeting.

Status
colourBlue
titlePlanned (with 4Science)

Status
colourYellow
titleInitiated

Status
colourGreen
titleinterested



Status
colourYellow
titleIdea
Status
colourBlue
titlePlanned (with 4Science)
Status
titleWorking on
Status
colourGreen
titleIn Production

Status
colourYellow
titleInitiated

Status
colourGreen
titleinterested



Status
colourYellow
titleIdea
Status
colourBlue
titlePlanned (with 4Science)
Status
titleWorking on
Status
colourGreen
titleIn Production

Status
colourYellow
titleInitiated

Status
colourGreen
titleinterested



Status
colourYellow
titleIdea
Status
colourBlue
titlePlanned (with 4Science)
Status
titleWorking on
Status
colourGreen
titleIn Production

Status
colourYellow
titleInitiated

Status
colourGreen
titleinterested



Status
colourYellow
titleIdea
Status
colourBlue
titlePlanned (with 4Science)
Status
titleWorking on
Status
colourGreen
titleIn Production

Status
colourYellow
titleInitiated

Status
colourGreen
titleinterested



Status
colourYellow
titleIdea
Status
colourBlue
titlePlanned (with 4Science)
Status
titleWorking on
Status
colourGreen
titleIn Production

Status
colourRed
titleIn Production

Based on DSpace-CRIS 5

...