Contribute to the DSpace Development Fund
The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.
Sprint 1: May 7-18, 2018
Sprint 1 Schedule
- Sprint 1 Meetings (Please do your best to attend all three meetings. If you cannot attend a meeting, please touch base with Tim Donohue for any updates, etc.)
- Sprint 1 Kick Off Meeting (one hour): Monday, May 7 at 14:00UTC (10:00am EDT) in DSpace Meeting Room
- Mid-Sprint Meeting (one hour): Monday, May 14 at 14:00UTC (10:00am EDT) in DSpace Meeting Room
- Sprint Wrap-Up (Closing) Meeting (one hour): Friday, May 18 at 14:00UTC (10:00am EDT) in DSpace Meeting Room
- Daily Standups are on #dev-sprint Slack. Just provide your daily updates via text chat, prior to 15:00UTC each day.
- More information on Sprint Schedule / Meetings can be found at Sprint Schedule
Sprint Goals
(NOTE: Currently these goals are very high-level. They need to be broken down into specific tasks / tickets prior to the Sprint, so that those tickets are claimable by individuals.)
- Alphabetic jump to (specific letter) in results listing
- E.g. Jump to a Title / Author starting with a specific letter or string, like http://demo.dspace.org/xmlui/browse?type=title
- Build out Administrative Search/Browse tools (each of these tools is limited to Site Administrators)
- Find Item by Internal Item ID/Item Handle (e.g. XMLUI: http://demo.dspace.org/xmlui/admin/item , JSPUI: http://demo.dspace.org/jspui/tools/edit-item)
- Administrative Search feature, which allows for faceted searching & browsing of "hidden" items. This feature would replace the following two Administrative Browse use cases (by providing a way to filter items by withdrawn status and/or private status)
- Browse Withdrawn Items (by Title) (e.g. XMLUI: http://demo.dspace.org/xmlui/admin/withdrawn , JSPUI: http://demo.dspace.org/jspui/dspace-admin/withdrawn)
- Browse Private Items (by Title) (e.g. XMLUI: http://demo.dspace.org/xmlui/admin/private , JSPUI: http://demo.dspace.org/jspui/dspace-admin/privateitems)
- Administrative Edit Item form
- Build a simple edit item form that mirrors the existing XMLUI and JSPUI edit item pages (e.g. XMLUI: http://demo.dspace.org/xmlui/admin/item, JSPUI: http://demo.dspace.org/jspui/tools/edit-item)
- This form should allow Administrators to add/update/delete any metadata field values for this item.
- This form should allow Administrators to withdrawn/reinstantiate the item
- This form should allow Administrators to make the item discoverable/private
- This form should allow Administrators to add/update/delete bitstreams attached to the item.
- This form should allow Administrators to delete an item
- Build a simple edit item form that mirrors the existing XMLUI and JSPUI edit item pages (e.g. XMLUI: http://demo.dspace.org/xmlui/admin/item, JSPUI: http://demo.dspace.org/jspui/tools/edit-item)
- Improve developer documentation / getting up-to-speed documentation.
UI Tasks
These are somewhat lower level than the goals above, in order to get an idea of the effort required, but need more detail before they can be turned in to github issues
Alphabetic jump to (specific letter) in results listing
- Service
- Effort: 24h
To do
construct the Rest URL based on the params
parse the response
ensure everything gets cached properly
build remotedata objects for results
write tests
- StartsWithComponent
Effort: 16h
To do
- show letters as links
- show a startswith input
- handle the case for phone screens (too small to show the alphabet)
- call the service with the correct query
- links should work with js disabled
- component should be abstract enough to be used with any kind of list
- write tests
- Browse By Title Component
- Description
- has an alphabetic selector at the top
- shows an item list
- can be paged and sorted
- can be scoped by a community or collection
- can be filtered by a metadata field
- Effort: 8h
- To do:
- create the component
- configure the routes
- call the service with optional scope and metadatafield filters
- configure existing components for alphabetic filtering, object lists and pagination to work with the correct data
- write tests
- Description
- Browse By Metadata Field Component:
- Description
- has an alphabetic selector or a date selector at the top
- shows a list of metadata values
- can be paged and sorted
- links go to a browse by title view filtered by the scope and the metadatafield of this component
- Effort: 16h
- To do:
- create the component
- configure the routes
- configure existing components for alphabetic filtering, object lists and pagination to work with the correct data
- create a component to select by date
- reuse the search’s date widget?
- Create an object list entry for metadata values
- the metadatafield it works with should be configurable: title, author, subject, etc.
- this should reflect in the route e.g.
/collection/:id/browse/title
- and the i18n labels.
- It should work with or without a scope
- write tests
- Description
Build out Administrative Search/Browse tools (each of these tools is limited to Site Administrators)
Find Item by Internal Item ID/Item Handle
- Routing by handle
- Effort: 24h
- To do:
- Create an index that maps handles to self links
- Modify the DSOResponseParsingService, to update the handle index every time an object is added to the cache
- add hasByHandle and getByHandle methods to ObjectCacheService
- modify RequestService.configure to check by handles as well to determine if something is cached.
- perhaps make the fields to check for configurable, I could imaging a check by DOI for example
- Add findByHandle to DataService
- configure handle based routes, that redirect to the DSOType based route
- write tests
- Find Item admin component
- Examples:
- Effort: 8h
- To do:
- write a component that allows you to enter the ID or handle
- on submit, determine whether it’s an id or a handle, and redirect to its edit page
- configure the route, using a guard that limits access to authorized users
- ensure the return button on the edit page returns you to the Find Item admin page
- preferably by using the route history in the store (or even browser history) rather than specifying the source page as a param
- write tests
Administrative Search
- Current Browse Withdrawn By Title:
- Current Browse Private By Title:
- Effort: 12h
- To do:
- configure the route, using a guard that limits access to authorized users
- create the component based on the search page component
- Use the set of facets for the administrative search. These will be configured on the rest side, and should contain a section to facet on withdrawn and private items
- Add labels to the search result components for withdrawn and private items. Use bootstrap's warning style labels, add them to the front of the author row.
- write tests
REST Tasks
These are somewhat lower level than the goals above, in order to get an idea of the effort required, but need more detail before they can be turned in to JIRA issues
Alphabetic jump to (specific letter) in results listing
- Add REST method to compute the offset / specify the offset as a startWith
- Effort: 4h
To do
write the contract (see https://github.com/DSpace/Rest7Contract/pull/23)
add support for the new parameter
write tests
- must work with both item level browse than metadata browse
- must respect the error codes specified in the contract
Build out Administrative Search/Browse tools (each of these tools is limited to Site Administrators)
Find Item by Internal Item ID/Item Handle
- Find a DSpaceObject by identifer (handle)
- Effort: 8h
- To do:
- write the contract (it should be a redirect to the specific items/communities/collections endpoint)
- implement a new dedicated controller
- write tests
- valid identifiers
- unvalid identifiers
Administrative Search
- Effort: 24h
- To do:
- introduce special withdrawn and private prefix for discover configuration
- enable the discover controller to search over withdrawn and private items
- fix the "public search" configuration to exclude withdrawn / private items
- write a default discover configuration that reuse the default filters / facets
- write a SolrSearchPlugin to exclude withdrawn and private items to non-administrators
- write tests
Build out Administrative Edit item
Metadata representation
- Express the metadata in the DSpaceObject as a map
- Effort: < 8h
- To do:
- replace the List<MetadataEntryRest> metadata in the DSpaceObjectRest with the Map<String, List<MetadataValueRest>> metadata used in the DataDescribe section of the workspaceItem (see https://github.com/DSpace/Rest7Contract/blob/master/workspaceitems.md#single-item)
- update all the tests to reflect the new structure
- update the REST contract samples
Patch items
- Add/Remove/reorder metadata
- Effort: 24h
- To do:
- write the contract (it must be based on PATCH)
- implement the patch method in the Item repository using a support class so to be reusable for each DSpaceObject (Collection, Community, EPerson, ...)
- write tests
- Withdrawn, Reinstatiate, make private or discoverable an item
- Effort: 8h
- To do:
- write the contract (it must be based on PATCH)
- implement the patch method in the Item repository
- write tests
Delete an item
- Effort: 8hr
- To do:
- write the contract (it must be a DELETE on the item endpoint)
- implement the method in the item repository, it should consider where the item is used (it could be a template of a community/collection or wrapped in a workspace/workflow)
- write tests
Manage bitstreams
- Add bitstreams to an existent item
- Effort: 8hr
- To do:
- write the contract (it should be based on POST multipart)
- implement the method in the Item repository, it should be possible to specify the Bundle where the bitstream will be created
- write tests
- Delete bitstreams in an item
- Effort: 8hr
- To do:
- write the contract (it must be a DELETE on the bitstreams endpoint)
- implement the method in the bitstream repository, it should consider where the bitstream is used (it could be a logo of a community/collection)
- write tests
- Reorder the bitstreams of an item (out-of-scope?)
- Effort: ???
- To do:
- write the contract (it should be based on PATCH... is the current item representation good enough?)
- implement the method
- write tests