Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • (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. 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.
    2. (REST) (beta 3) Subresources should obey access restrictions https://github.com/DSpace/DSpace/pull/2726 (Requires more analysis / brainstorming)
    3. As noted last week, currently in the REST API, we do not fully support Community or Collection Admins adding/managing Community/Collection Groups
      1. Related to 
        Jira
        serverDuraSpace JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyDS-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?"
    4. 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
    5. (Feel free to add other topics)
  • (20 mins) Planning for next week

...