Page History
...
- Improving performance / scalability in general
- High CPU usage for server-side rendering, https://github.com/DSpace/dspace-angular/issues/3110
- Unable to route network requests to different REST URL during server-side rendering (public vs private REST requests): https://github.com/DSpace/dspace-angular/issues/1485
- Serve REST configuration more efficiently: https://github.com/DSpace/DSpace/issues/9056
- User permissions should be obtained in fewer REST requests: https://github.com/DSpace/dspace-angular/issues/3161
- Submission Form should be loaded using fewer REST requests: https://github.com/DSpace/dspace-angular/issues/3162
- Search Results should be loaded using fewer REST requests: https://github.com/DSpace/dspace-angular/issues/3163
- Enabling Configurable Entities (by default)
- What do we need to achieve to enable Entities by default?
- How can entities be made more usable?
- Improving scalability/performance/functionality of Relationships
- Nested/hierarchical metadata (e.g. dates on a Person's affiliation with an OrgUnit)
- If entities are enabled by default how could a migration look like? Shall we offer a script to add a field dspace.entity.type="Publication" to all items without an entity type?
- Convert a Relationship to a DSpaceObject - it will benefit of all the DSpaceObject has to offer, like: metadata, resource policies
- Easier Installation and Upgrades
- Discussions around simplifying installation process: https://github.com/DSpace/dspace-angular/issues/3184
- Use "npm" instead of "yarn" for frontend installation: https://github.com/DSpace/dspace-angular/pull/3173
- Can we simplify the installation/upgrade process of DSpace, especially now that there's a frontend & backend to manage?
- Modularization
- Angular : library-based architecture proposal - As of 8.0, we've already migrated to "standalone components". We can now consider whether to potentially migrate to using Nx.
- Code Cleanup / Maintenance
- Dependency upgrades: Upgrade to Angular 18 & Spring Boot 3.3
- Replace Submission Form library (as the one we use is unmaintained): https://github.com/DSpace/dspace-angular/issues/2216
- All collections should have a workflow – a default noninteractive workflow would facilitate applying curation tasks (such as virus scanning) to all submissions: https://github.com/DSpace/
- Permissions
- Possibility of granting granular permission to individuals and groups to edit / see only some metadata
- 8820
- Shall we automatically change metadata in flyway migrations?
- DOIs
- Changing the field a DOI is using (dc.identifier.uri vs. dc.identifier.doi)
- Changing the resolver (https://doi.org vs. http://dx.doi.org
- )
- DOIs
- Enabling Configurable Entities by default (Potential alignment with DSpace-CRIS?)
- What do we need to achieve to enable Entities by default?
- How can entities be made more usable?
- Improving scalability/performance/functionality of Relationships
- Basic Nested/hierarchical metadata (e.g. dates on a Person's affiliation with an OrgUnit). Related also to https://github.com/DSpace/DSpace/issues/9736
- If entities are enabled by default how could a migration look like? Shall we offer a script to add a field dspace.entity.type="Publication" to all items without an entity type?
- Convert a Relationship to a DSpaceObject - it will benefit of all the DSpaceObject has to offer, like: metadata, resource policies
- ModularizationAll collections should have a workflow – a default noninteractive workflow would facilitate applying curation tasks (such as virus scanning) to all submissions:
- Angular : library-based architecture proposal - As of 8.0, we've already migrated to "standalone components". We can now consider whether to potentially migrate to using Nx.
- Do we need a UI/UX guide to enable module developer to achieve a common "DSpace" look and feel?
- Enhanced Statistics for DSpace (volunteer: Paulo Graça )
- Paulo volunteered to perhaps start an interest group / working group around Statistics enhancements as his organization is interested in enhancing this for DSpace.
- Features which existed in DSpace 6 (and earlier)
- Bitstream persistence URLs - As of DSpace 7, there are no persistent URLs for bitstreams. The URL is based on UUID, and if you replace or version a bitstream the URL will change: https://github.com/DSpace/DSpace/issues/9083
- CMS - bringing back old features to new the DSpace version like the ability to the admin user to change content like: news, default license,... https://github.com/DSpace/dspace-angular/issues/3200
- Administrative User Interface enhancements/improvements
- Associate submission forms to collections in the UI - https://github.com/DSpace/dspace-angular/issues/3194
- The bitstream permissions flow is confuseconfusing, we should improve the usability - https://github.com/DSpace/dspace-angular/issues/3203
- Any DSpaceObject, like a Bitstream can have custom fields. After creation, there should be a place in the UI to view and edit them
- Communities/Collections: there should be a wayin the UIto move sub-communities to a different place: https://github.com/DSpace/dspace-angular/issues/3196, https://github.com/DSpace/dspace-angular/issues/3198
- Permissions: Possibility of granting granular permission to individuals and groups to edit / see only some metadata
- Results of DCAT UX Project Team Testing
Priorities for 9.0
To be decided. 9.0 is still in very early planning phase. Priorities have not yet been established.
...
Overview
Content Tools