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.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Date

 from 14:00-15:00 UTC

Location: https://lyrasis.zoom.us/my/dspace (Meeting ID: 502 527 3040).

Planning Sprint : April 20-April 24

Agenda

  • (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  Unable to locate Jira server for this macro. It may be due to Application Link configuration.  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

Attendees

7.0 Release Goals

These resources define the prioritization and general schedule we are working towards

Current Work

Legend for status icons

(blue star) = Highest Priority tasks (please prioritize these reviews/tasks over others).

(error) = review done, changes were requested or bugs found.

(tick) = review done, approved.

(warning) = review done, merge conflict or other minor changes requests

1 APPROVAL = pull request only requires a single approval to merge.  This is generally reserved for PRs which are either smaller, obvious, and/or bug fixes with tests to prove they work.  

Claim a Ticket!

If you do not have access in JIRA or GitHub to officially claim the ticket you wish to work on, contact Tim Donohue

PRs Needing Review

  1. (REST Contract) related to the scripts & processes PR above (related to PR 2648 below) https://github.com/DSpace/Rest7Contract/pull/99 ((warning)NEEDS UPDATES FROM Kevin Van de Velde (Atmire) ) (Andrea Bollini (4Science) - (error) REVIEWEDTim Donohue )
  2. (REST Contract) Language support on the backend (possible new cookie for Angular?https://github.com/DSpace/Rest7Contract/pull/122 (Tim DonohueBen Bosman, Art Lowel (Atmire) )
  3. (REST) (beta4) Scripts & processes: importing and exporting csv's https://github.com/DSpace/DSpace/pull/2648 ((warning)WAITING ON PR UPDATES FROM Kevin Van de Velde (Atmire) ) (Andrea Bollini (4Science) - (error) REVIEWEDTim Donohue - added summary of way forward Mark H. Wood  )
  4. (REST) (tentative 7.1) [DS-4281]: Metadata suggestions in the live import https://github.com/DSpace/DSpace/pull/2712 (NEEDS TICKET / DISCUSSION) (Tim Donohue - (warning) I believe this is a new feature? We should add this to the spreadsheet, Andrea Bollini (4Science), agree with Tim it is a new feature so postpone compared to existing features)
  5. (REST) (beta 3) Subresources should obey access restrictions https://github.com/DSpace/DSpace/pull/2726 (Tim Donohue  -(warning)New feedback added, Andrea Bollini (4Science) (error) implementation approach need discussion)
  6. (REST) (beta 3) Administer Workflow (Abort WorkflowItem, Delete WorkflowItem) https://github.com/DSpace/DSpace/pull/2727 (Ben Bosman's team is checking out if this can be changed per Andrea's suggestions) (Tim Donohue - (warning) feedback added, approach seems fine though, Andrea Bollini (4Science) (error) implementation approach need discussion)
  7. (REST) Configurable whitelist for "Access-Control-Allow-Origin" header: https://github.com/DSpace/DSpace/pull/2735 (Ben Bosman , Giuseppe Digilio (4Science))
  8. (REST) (beta 3) Account profile management https://github.com/DSpace/DSpace/pull/2747 (Tim DonohueAndrea Bollini (4Science))
  9. (REST) Assume login feature https://github.com/DSpace/DSpace/pull/2740 (Ben BosmanTim Donohue - (warning) Feedback added, Andrea Bollini (4Science) - (warning) Feedback added)
  10. (REST) (beta 3) Controlled vocabulary Mykhaylo Boychuk https://github.com/DSpace/DSpace/pull/2743 (REST Contract #120) (Tim Donohue, NEEDS SECOND REVIEWER)
  11. (Angular) (beta 3) Edit resource policies https://github.com/DSpace/dspace-angular/pull/645 (Tim DonohueArt Lowel (Atmire) , (tick) Julian Timal (eScire) )
  12. (Angular) (beta 3) Administer Workflow https://github.com/DSpace/dspace-angular/pull/650 (Tim DonohueJulian Timal (eScire))
    1. Depends on REST PR #2727 (see above). NEEDS FEEDBACK ON #2727
  13. (Angular) (beta3) Scripts & Processes Admin UI https://github.com/DSpace/dspace-angular/pull/636 (Tim DonohueGiuseppe Digilio (4Science)Craig Rosenbeck)
    1. Depends on REST PR #2648 (see above)
  14. (blue star) (Angular) (EARLY beta3) Switch to Angular CLI https://github.com/DSpace/dspace-angular/pull/625 (Tim DonohueGiuseppe Digilio (4Science)(warning)Reviewed and feedback added)
  15. ((Angular) Alternative links https://github.com/DSpace/dspace-angular/pull/652 (Giuseppe Digilio (4Science)Tim Donohue)
  16. (Angular) Login as EPerson  https://github.com/DSpace/dspace-angular/issues/653 (Tim Donohue , Giuseppe Digilio (4Science) ,Julian Timal (eScire))
    1. Known HTML caching issue needs feedback: https://github.com/DSpace/dspace-angular/issues/654
    2. Depends on REST PR #2740 (see above)
  17. (Backend) DS-626 : Exchange usage data with IRUS https://github.com/DSpace/DSpace/pull/2664 ((tick)Craig RosenbeckNEEDS SECOND REVIEWER)
  18. (Backend) (tentative 7.2) DS-4440 GDPR - Anonymize Statistics Feature: https://github.com/DSpace/DSpace/pull/2692 (Andrea Bollini (4Science)Ben BosmanTim Donohue)
  19. (blue star) (Backend / Security) (EARLY beta3) Upgrade Spring Boot, Spring & Spring HATEOAS: https://github.com/DSpace/DSpace/pull/2720 (Andrea Bollini (4Science) - REVIEW BY APRIL 23(tick)Craig Rosenbeck)

PRs Coming Soon

  1. (beta 3) REST Language Support on the backend Mykhaylo Boychuk ETA 17 or 20 April

PRs Merged this week!

  1. (tick) (blue star) (REST) (beta 2) Edit Community/Collection - Assign Roles/Groups https://github.com/DSpace/DSpace/pull/2722
  2. (tick) (blue star) (Angular) (beta2) Edit Community - Assign Roles/Groups https://github.com/DSpace/dspace-angular/pull/632
  3. (tick) (blue star) (Angular) (beta2) Edit Collection - Assign Roles/Groups https://github.com/DSpace/dspace-angular/pull/643
  4. (tick) (REST Contract) Configuration property retrieval https://github.com/DSpace/Rest7Contract/pull/119

Blocked

  1. (Blocked PRs go here)

Delayed / Needs Discussion

  1. Managing Authorization info in Angular UI How to pass Authorization rights (i.e. logged in user's access rights) from REST API to Angular?  See for example:  https://github.com/DSpace/dspace-angular/issues/393
    1. In July 25 meeting, we noted this probably cannot be resolved with just one simple solution. May need to look at different options for different scenarios
    2. Work is ongoing, but has been started in these areas:
      1. Summary of ideas: REST Authorization 
      2. Contract for Authorization Endpoints: https://github.com/DSpace/Rest7Contract/pull/92
      3. Contract for ResourcePolicies: https://github.com/DSpace/Rest7Contract/pull/87
  2. Initial Performance Testing from Chris.
    1. https://cwilper.github.io/dspace-perftest/
  3. (REST Contract) Edit Homepage News: https://github.com/DSpace/Rest7Contract/pull/45
    1. Delayed. General agreement (in meeting on March 21, 2019) that storing HTML in metadata fields is not really ideal behavior.  Metadata (from a librarian standpoint) tends to be free of format-related markup (as that allows for easier sharing, understanding of metadata.  Currently Community & Collection homepage information is HTML-based and is stored in metadata that is appropriate for a minor subset of information (like the title) but it is better to move large/rich text to bitstreams.  
    2. Proposal here is to consider storing HTML-based markup (for Site, Community & Collection homepages) in Bitstream(s) associated with the object in question.  May allow for more CMS-lite behavior in the future
    3. Timeline for this is uncertain.  Possibly in 7 or 8. May depend on how/whether it can be scoped.
  4. (warning) (Angular Bug) https://github.com/DSpace/dspace-angular/issues/368 ( Art Lowel (Atmire) )
  5. Concurrency in DSpace 7 (or 8).  What do we want to do when multiple editors are editing the same object?  Needs further analysis regarding implementation details
    1. We've decided (in meeting on March 7, 2019) to use ETags to implement concurrency. REST Contract notes on ETags: https://github.com/DSpace/Rest7Contract#etags--conditional-headers
    2. ETags only update of the two fields match. If someone edits first, your edit would fail and you would get a fail response (422?)
    3. ETags seems to have broader support in other REST APIs.  Recommended also by both Art and Andrea.

Notes




  • No labels