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
  
  1. Revisiting "Collection dropdown in submission" issues (how should we address these?  Beta 3 has several other submission tickets, should we include work on these?)
     
     1. 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)
     2. Changing Collection doesn't work when new collection has a different form definition: https://github.com/DSpace/dspace-angular/issues/621
        1. If I recall correctly, Collection item templates also are not working right in this scenario.
        2. And I don't recall whether previously entered metadata gets saved or cleared out when collections have different metadata requirements.
        3. 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).
     3. somehow related to this discussion Creation of DSpace Entities
  2. (REST) (beta 3) Subresources should obey access restrictions https://github.com/DSpace/DSpace/pull/2726 (Requires more analysis / brainstorming)
  3. 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)
     1. Review current spreadsheet (from Andrea Bollini (4Science) ) : https://docs.google.com/spreadsheets/d/1182LcD_WqIZRbUGWpLtBw0aOMR9jhbOVB7GZqtTpR9A/edit?usp=sharing
  4. Restricted endpoints are sometimes the only HAL link path to public endpoints (

     Jira
     server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key DS-4495

     )HAL links on restricted endpoints with public children
     1. Some endpoints don't allow you to GET them, but do have publicly accessible child endpoints (e.g. registrations, resourcepolicies, …). To get to those child endpoints the UI can't discover them because the parent endpoint returns a 4xx status code. We should consider a way to prevent a regular response but allow retrieving the HAL links
  5. Tabled Topics (two were tabled for future discussion)
     1. (PR from Kevin coming?) We do not fully support Community or Collection Admins adding/managing Community/Collection Groups
        1. Related to 

           Jira
           server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key DS-4486

            and this brainstorm REST Contract PR
        2. 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. 
        3. 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?"
     2. (On hold for beta5 and then 7.1) Live Import Feature & "Metadata Suggetions" per https://github.com/DSpace/DSpace/pull/2712
        1. Live Import was definitely in DSpace 6.x: 2016 Framework for live import from external sources
        2. 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.
  6. (Feel free to add other topics)
• (20 mins) Planning for next week
  
  • Claim tasks for next week from DSpace 7 Release Plan spreadsheet
  • Assigning PRs for Review

...