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.
• (30 mins) General Discussion Topics
  
  1. (10 mins) Tim summarizes next steps for BTE vs Live Import 

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

     
     
     1. BTE framework was deprecated in 6.0, with Live Import framework selected as the replacement. 
     2. As discussed previously, the "Metadata Suggestions" PR (https://github.com/DSpace/DSpace/pull/2712) includes useful enhancements to Live Import functionality (from how it existed in 6.x).  However, this doesn't quite replace existing BTE functionality.
     3. Tim Donohue's recommendation is to start from a PR that implements a more simplistic implementation of Live Import that can be used to swap out BTE more directly.  Would this be possible?
        1. The idea would be to start small here with a basic PR that disables/replaces BTE from REST API in favor of Live Import. The focus would be on replacing/refactoring the two `dspace-server-webapp` classes that touch BTE as documented in this JIRA comment
        2. We would then follow that up with additional PRs to add/enhance functionality of Live Import to better align with (other) existing features in BTE.  Including PR#2712, but also including support for additional formats/services and perhaps improved command-line support (if deemed necessary)
     4. Ben Bosman has suggested that we might consider creating a BTE "plugin" for Live Import to help with the transition.  This will allow us to build all DSpace 7 features using the Live Import framework, while (temporarily) allowing BTE features/functions to still be able to work via Live Import. (Tim notes that this should only be temporary to avoid short term feature loss.  The end goal should still be one framework.)
     5. If others feel necessary, a separate meeting specific to BTE & Live Import could be scheduled to talk through the details of this change.
  2. (10 mins) (REST) (beta 3) Subresources should obey access restrictions https://github.com/DSpace/DSpace/pull/2726 
     1. Tim Donohue added feedback to the PR based on testing/analysis of Spring Security annotations: https://github.com/DSpace/DSpace/pull/2726#issuecomment-622581818
  3. (10 mins) How to move forward on Controlled Vocabulary feature: https://github.com/DSpace/DSpace/pull/2743
     1. Ben Bosman added feedback on feature gaps between DSpace 6 and DSpace 7 with regards to Controlled Vocabulary. How can we work to address these gaps in upcoming PR(s)?
     2. Early notes on differences in behavior: Controlled Vocabularies and Authority Control in DSpace 7
     3. This topic may be short on time, however if someone(s) is willing to draft a proposal for addressing these gaps, we can revisit next week.
  4. Tabled Topics (will not be discussed unless time allows)
     1. 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

        )
        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
     2. 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 
     3. PROPOSAL FROM 4SCIENCE https://wiki.lyrasis.org/x/jwUoCw
        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?)
        2. 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)
        3. 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).
        4. somehow related to this discussion Creation of DSpace Entities
• (15 mins) Planning for next week
  
  • Claim tasks for next week from DSpace 7 Release Plan spreadsheet
  • Assigning PRs for Review

...