Sprint Weeks
- April 23 - 27 and April 30 - May 4
- April 30 - May 4 and May 7 - 11
- May 7 - 11 and May 14 - 18 (Current front runner)
Participants
(NOTE: Please refrain from signing up until the Sprint dates are finalized. This will ensure you are able to contribute during the Sprint. An announcement will be sent to mailing lists & Slack when signup is open/available. In the meantime, you are welcome to comment on this Sprint or the framework via comments to this Wiki page)
Sprint Coaches
Coaches should be available during the full sprint for help getting up to speed / answering questions / debugging issues / pair programming requests, etc.
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 (NOTE: Below browse tasks have a dependency on this feature. Should we do this prior to the sprint?)
- 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)
- 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)
- 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
- 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
- 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
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
Browse Withdrawn Items (by Title)
- Examples:
- Effort: 12h
- To do:
- configure the route, using a guard that limits access to authorized users
- create the component based on the browse by title component
- add
findWithdrawn(startsWith: string): Observable<RemoteData<PaginatedList<Item>>> to ItemDataService- it should determine the correct URL to request on the backend, the rest should already be in place from other findBy methods.
- write tests
Browse Private Items (by Title)
- Examples
- Effort: 12h
- To do:
- configure the route, using a guard that limits access to authorized users
- create the component based on the browse by title component
- add
findPrivate(startsWith: string): Observable<RemoteData<PaginatedList<Item>>> to ItemDataService- it should determine the correct URL to request on the backend, the rest should already be in place from other findBy methods.
- write tests