...
Who? | What? | Note | Status | ||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Improve the ORCID login flow solving the issue related to private email address in the ORCID profile and/or discrepancy among the ORCID's email and the one in the existing DSpace EPerson | This project has been funded by ORCID under their GPF program. More details here Improvements to the Login Flow |
| ||||||||||||||||||||||||||||||||||||||||||||
| 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. |
| ||||||||||||||||||||||||||||||||||||||||||||
| 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-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. 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. 05/2024 : We have received the source code |
| |||||||||||||||||||||||||||||||||||||||||||||
| 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). |
| ||||||||||||||||||||||||||||||||||||||||||||
| Set user for command line operations | On 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. |
| ||||||||||||||||||||||||||||||||||||||||||||
| https://github.com/4Science/DSpace/issues/419 Bitstreams listed in the advancedattachment CRIS Layout option are not sorted correctly | Bug on the itempages (at least with the advancedattachment rendering in DSpace-CRIS): the files are sorted randomly and the sort order from bundle2bitstream.bitstream_order is ignored. Anyone having trouble with that as well? |
| ||||||||||||||||||||||||||||||||||||||||||||
| https://github.com/4Science/dspace-angular/issues/66 Version information not visible on DSpace-CRIS itempages | The version information with a reference to the latest version and a version history for versioned items is not displayed on DSpace-CRIS itempages (in fact, it is visible on the full item view page and on generic DSpace 7, but not on DSpace-CRIS) |
| ||||||||||||||||||||||||||||||||||||||||||||
Organization Unit Tree https://github.com/4Science/DSpace/issues/386 https://github.com/4Science/DSpace/pull/383 | Implementation of some organization unit tree which shows the hierarchical structure of Orgunits together with some metrics for each tree node. The tree is included as some extra section component. For each tree node metrics are calculated using solr queries or they are aggregated from subordinate nodes. The tree node is delivered through some new Rest endpoint. Some working example can be shown on https://fis.uni-bamberg.de/explore/orgunits |
| |||||||||||||||||||||||||||||||||||||||||||||
| Orcid Push of Product Entity https://github.com/4Science/DSpace/issues/426 https://github.com/4Science/DSpace/pull/428 https://github.com/4Science/Rest7Contract/pull/5 https://github.com/4Science/dspace-angular/pull/73 Orcid Push of Patent Entity https://github.com/4Science/DSpace/issues/431 | Push of Product Entity to Orcid as Orcid Work. The Push uses some own mapping Factory and thus can be configured in the same way as the Orcid Push oif Publicationsof Publications. The same way/changes have been adopted to the Patent Entity. |
since 2023.02.03 | ||||||||||||||||||||||||||||||||||||||||||||
| "Associate" Item https://github.com/4Science/DSpace/issues/365 https://github.com/4Science/DSpace/pull/382 | Extension of the edit-item mode which allows some user to "associate" some project to some publication (e.g. Publication dc.relation.project holding the reference to the project), although the permissions for editing the publication are missing. We use the terminus associate because connect, related, interlinking etc... and other synonyms are all already used in DSpace speech. |
| ||||||||||||||||||||||||||||||||||||||||||||
| MINE / MY_SELECTED orcid sync settings https://github.com/4Science/DSpace/issues/348 https://github.com/4Science/DSpace/pull/351 https://github.com/4Science/Rest7Contract/pull/6 https://github.com/4Science/dspace-angular/pull/38 | Implementation of Orcid Sync Settings for relationship based preferences (existed in DSpace 5). This allows profile owners to push only selected publications/fundings (MY_SELECTED) or all non-hidden publications/fundings (MINE) to orcid. |
| ||||||||||||||||||||||||||||||||||||||||||||
)
| Enhancement ToolsVersioning by metadata https://github.com/4Scienceuniba-ub/DSpace/issuestree/357uniba-versioning | Part of the versioning logic used by university of Bamberg, as previously presented at https://doi.org/10.20378/irb-53684 (german only) for DSpace5 by metadata. Add some context-menu button and endpoints to create some version/copy of some item as own workspaceitem. The reference between versions (isversionof/hasversions 1 to n) is hold in reciprocal metadata. Another functionality is to change the main version (which hasversions and in our case is discoverable) within some version group by another button in the context-menu |
| ||||||||||||||||||||||||||||||||||||||||||||
| Enhancement Tools https://github.com/4Science/DSpace/issues/357 https://github.com/4Science/DSpace/pull/440 https://github.com/4Science/DSpace/pull/441/4Science/DSpace/pull/312 | The item-enhancer is usually some long-running process which runs over all items. We made some forks of the item-enhancer script: 1. only consider certain entity type or collection 2. only consider items of some solr-query, e.g. only recently changed. Both approaches limit the amount of items being processed and allow some fine-granular (re)calculation of virtual metadata. In addition there has been some improvements to the Commitment of the Context. The tools also contains some NameEnhancer which can be used to calculate the dc.title from several other metadatafield in their order of appearance. |
| ||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||
|
|
...