...
Who? | What? | Note | Status | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 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) |
| ||||||||||||||||||||||||||||||||||||
| Importing items as private with bulk import | On 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? |
| ||||||||||||||||||||||||||||||||||||
| 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 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. |
| ||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||
|
|
...