| Priority 1 Features | Design / Notes | Related Technical Strategic Goal(s) | Core? | Complexity | Use Cases | Work in Progress? |
|---|
| Anchor |
|---|
| Single User Interface |
|---|
| Single User Interface |
|---|
|
Single User Interface. (Work has begun in DSpace 7 Working Group) | DSpace currently maintains two user interfaces in parallel (JSPUI and XMLUI). To replace these two user interfaces, we are building a new, single, out-of-the-box user interface on Angular.io. | Goal 2: Lean and flexible | x | High | For reference: Also see: DSpace 7 UI Project Plain Language Summary | 
|
| Anchor |
|---|
| Standards-based REST API |
|---|
| Standards-based REST API |
|---|
|
Standards-based REST API (Work has begun in DSpace 7 Working Group) | DSpace's current REST API, while functional, is limited in features and does not follow current best practices for RESTful APIs. To support the new, single user interface (on Angular.io), we are building / designing a new REST API that follows modern best practices such as: HATEOAS, ALPS, and using the HAL response format. The new REST API is being built using Spring technologies (Boot, MVC, and HATEOAS). | Goal 3: Can be "extended" and Goal 4: Integration with external services | x | High | New REST Contract (work in progress): | |
| Anchor |
|---|
| Single Approval Workflow system |
|---|
| Single Approval Workflow system |
|---|
|
Single Approval Workflow system.
(Work has begun in DSpace 7 Working Group) | DSpace currently has two approval workflow systems: - Basic/Traditional Approval Workflows. These are enabled by default, and provide up to three approval steps: "Approve/Reject", "Approve/Reject/Edit", or "Edit". These are described in more detail in the Functional Overview#WorkflowSteps
- Configurable Workflow (XMLUI only, and requires migrating all Basic/Traditional workflows)
We should consolidate on a single Approval Workflow system, likely the Configurable Workflow, with sane defaults. | Goal 1: Fundamentals of IR | x | Medium | | Jira |
|---|
| server | DuraSpace JIRA |
|---|
| serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
|---|
| key | DS-3041 |
|---|
|
| |
| Anchor |
|---|
| Single built-in Statistical Engine |
|---|
| Single built-in Statistical Engine |
|---|
|
Single built-in Statistical Engine (SOLR Statistics)
Elasticsearch Usage Statistics were deprecated in 6.0 and will be removed in 7.0
| DSpace currently has three built-in statistical engines, one based on Apache Solr (default), another based on Elasticsearch (optional), and a third Legacy statistics (which parses logs). DSpace should only provide one out-of-the-box, built-in statistical engine (Solr Statistics), and all others should be removed (and as necessary, their features merged into one).
| Goal 2: Lean and flexible | x | Medium | | |
| Anchor |
|---|
| Configurations in Admin User Interface |
|---|
| Configurations in Admin User Interface |
|---|
|
Configurations in Admin User Interface | DSpace should support the modification of most configurations/settings from the Administrative User Interface, instead of requiring such configurations be tweaked from command line.
- Dependent on / related to "Single User Interface"
| Goal 5: Low cost, "just works" | x | High |
| Expand |
|---|
| title | Configuration Use Cases |
|---|
| | Content by Label |
|---|
| showLabels | false |
|---|
| max | 30 |
|---|
| spaces | DSPACE |
|---|
| showSpace | false |
|---|
| cql | label = "uc-configuration" and space = "DSPACE" |
|---|
| labels | uc-configuration |
|---|
|
|
|
|
| Anchor |
|---|
| Module Framework and Registry |
|---|
| Module Framework and Registry |
|---|
|
Non-functional: Module Framework and Registry
| DSpace needs a clear definition of what constitutes a "DSpace module", so that third-parties can create, maintain and distribute their own "modules" as add-ons to DSpace, and distribute them via a public "registry". | Goal 3: Can be "extended" | x | High | | |
| Anchor |
|---|
| Lower the effort to deposit content |
|---|
| Lower the effort to deposit content |
|---|
|
Lower the effort to deposit content (via integrations) | The DSpace deposit process should integrate more closely with external data sources, in order to automatically populate (or suggest) data on deposit. We should also investigate whether some integrations may allow opportunities for Administrator's to autopopulate DSpace from trusted, external content sources. | Goal 1: Fundamentals of IR Goal 4: Integration with external services | x | Medium | | |