Page History
...
(15 mins) Developer Stand Up - Developers give brief updates on their effort (or their team's effort).
- Update/see "Current Work" section below based on your status. Please feel free to update prior to meeting.
- Please highlight any new work (needing reviews/testing), any blockers (for you), and any discussion topics you may have.
- (25 mins) General Discussion Topics
- Revisiting "Collection dropdown in submission" issues (how should we address these? Beta 3 has several other submission tickets, should we include work on these?)
- Known performance issues: https://github.com/DSpace/dspace-angular/issues/487 (NOTE: These are still reproducible on the demo site. If you load a new submission, there's a 4-5 second pause before the page becomes usable)
- Changing Collection doesn't work when new collection has a different form definition: https://github.com/DSpace/dspace-angular/issues/621
- If I recall correctly, Collection item templates also are not working right in this scenario.
- And I don't recall whether previously entered metadata gets saved or cleared out when collections have different metadata requirements.
- Since it's possible to start a new submission via a default Collection, this increases the likelihood of encountering these issues (if the deposit starts in the wrong collection).
- (REST) (beta 3) Subresources should obey access restrictions https://github.com/DSpace/DSpace/pull/2726 (Requires more analysis / brainstorming)
- As noted last week, currently in the REST API, we (PR from Kevin coming?) We do not fully support Community or Collection Admins adding/managing Community/Collection Groups
- Related to
and this brainstorm REST Contract PRJira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key DS-4486 - Currently, Community/Collection Admins do not have permissions to search/view all EPeople or Groups, nor can they view current members of the Group. These are all limited to full Administrators at this time.
- As discussed on April 16, the ideal solution would be to not change the REST API contract, but instead allow all Community/Collection Admins to have search/view permissions on all EPeople or Groups. However, this would require a way to easily determine if a user was a Community/Collection Admin in a manner that does not cause performance problems. For example, we would not want to have to load every Group or every Community/Collection to determine if the current user could manage/administer them. Instead, we'd want to see if there's a database level query that can answer the question: "Does the current user have Admin-level rights on one or more Communities or Collections?"
- Related to
- Finalize / approve the initial list of all authorization features which we should implement for the /api/authz/features REST endpoint. This list of features should be limited to only features which are required to enable/disable User Interface functionality. (In other words, we can always add more features in the future. We just need to approve the list necessary for 7.0)
- Review current spreadsheet (from Andrea Bollini (4Science) ) : https://docs.google.com/spreadsheets/d/1182LcD_WqIZRbUGWpLtBw0aOMR9jhbOVB7GZqtTpR9A/edit?usp=sharing
- Live Import Feature & "Metadata Suggetions" per https://github.com/DSpace/DSpace/pull/2712
- Live Import was definitely in DSpace 6.x: 2016 Framework for live import from external sources
- However, "Metadata Suggestions" seems like a new feature of Live Import? If this is accurate, we should track it separately so that it can have estimates & scheduling specific to it.
- (Feel free to add other topics)
- Revisiting "Collection dropdown in submission" issues (how should we address these? Beta 3 has several other submission tickets, should we include work on these?)
- (20 mins) Planning for next week
- Claim tasks for next week from DSpace 7 Release Plan spreadsheet
- Assigning PRs for Review
...
Overview
Content Tools