Page History

...

• DSpace 7 Planning discussion
  
  • Planning Spreadsheet has had a lot of work over last week: https://docs.google.com/spreadsheets/d/18brPF7cZy_UKyj97Ta44UJg5Z8OwJGi7PLoPJVz-g3g/edit?usp=sharing
    • Feedback: Status values need updating
      • Drop "1. planned". Everything on spreadsheet is planned.
      • Add in a new status prior to "7. completed".  Something like "Draft" or "Draft Implementation"
    • How to track documentation that needs to be done?  As another status? In JIRA / GitHub issues?
      • Decision: Add a new "Documentation" column for both REST and UI on the "Overview" tab. That can track documentation status.
    • ACTION: Tim to update spreadsheet and note on Slack when complete.
• DSpace Entities Mtg
  • DSpace Entities Working Group (2017-18)
  • Not directly applicable to DSpace 7, but may be of interest to folks here.  They are starting to discuss changes to DSpace data model (likely arriving in DSpace 8, at earliest).
  • Join the #entities-wg Slack channel and future meetings for more info. All meetings also recorded.
• Angular UI Team updates (via Art)
  • Merged: https://github.com/DSpace/dspace-angular/pull/213
  • Merged: https://github.com/DSpace/dspace-angular/pull/211
  • Angular 5 upgrade ready for review: https://github.com/DSpace/dspace-angular/pull/214
    • ACTION: Tim will download and test site with Angular 5.
    • ACTION: Art will also ping William Welling to see if he has chance to give a code review.
  • Bootstrap also needs upgrading (v4 released). This has been split into another ticket: https://github.com/DSpace/dspace-angular/issues/215
  • Next up:
    • Art is working on fixing Transfer State code for Angular 5. This is now built-in, we used to have to do this in a custom way: https://github.com/DSpace/dspace-angular/issues/200
    • In Angular 5, Rxjs has had an update. We'll need to refactor our code based on this (may be more little-by-little, rather than all at once).  Not a rush as the old way of chaining Rxjs operators is still supported (but may be removed by Angular 6). https://github.com/DSpace/dspace-angular/issues/201
      • ACTION: Art to add more examples to ticket of what to look out for, and how to correct this in code.
  • Lotte is working on search page truncation.  PR should be coming soon.
  • Question (Pascal): Considering the frequency of Angular updates, after DSpace 7 are we still planning to stick with our yearly release cycle (for major releases)?
    • YES, we have no plans to change DSpace's release cycle.  This may however mean that major releases of DSpace occasionally jump over an Angular release. (e.g. maybe DSpace 7 will use Angular 6, while DSpace 8 may use Angular 8).
    • Art notes that Angular has a formalized release cycle now as well. They do a major release every 6 months
    • Andrea notes that Angular update frequency will also affect institutions who have locally customized DSpace, or have custom plugins that modify the Angular UI.  We have to communicate this well, and keep them in mind too.
    • Art also notes that Angular provides great online tools for how to upgrade your local code between Angular releases. You can select what version you are on, and select what version you want to upgrade too, and they provide a checklist of all the changes you'll need to make to your local code.  We could share this as part of our DSpace Upgrade process in future.
    • In the future, we may want to ensure the "master" branch is always running the latest version of Angular.  But, we still won't cut a new major release more frequently.
  • Giuseppe notes he's hitting a few issues:
    • POST / PATCH requests aren't working correctly. The first request seems to be cached, but after that the caching is not seemingly working right
      • Art thought he fixed this in https://github.com/DSpace/dspace-angular/pull/211
      • However, Giuseppe notes he's running latest and still seeing this odd behavior
      • ACTION: Giuseppe will create a ticket for this, and link Art to his branch and/or sample code. That way we can see if Art can reproduce and find a solution.
    • Also issues with working with WorkSpace Items in Angular UI.  The DSpaceObject parser isn't working properly for this purpose?
      • Art notes we may need to change the code here to deal with them. But, likely needs more info from code to give more advice
      • ACTION: Giuseppe will create a ticket for this, and link Art to his branch and/or sample code. 
• Side discussion on Slack notifications
  • Are the Waffle board notifications for Angular tickets (in #angular-ui) useful?
    • Yes. let's leave them. Good to see activity as it is happening
  • Is there something we could similarly use for JIRA for the #rest-api channel?
    • Not sure.
    • Patrick noted a few possible plugins to investigate
      • https://dspace-org.slack.com/apps/A0F7YS3MZ-jira-server-alerts
      • https://dspace-org.slack.com/apps/A0F7YS2SX-github?page=1
    • ACTION: Tim will look into these plugins and report back
• REST API Updates (from Andrea)
  • No pull requests merged this week. But, lots of new activity / PRs created, which is great to see!
  • Shibboleth work from Terry (with feedback from Tom)
    • https://github.com/DSpace/DSpace/pull/1927
    • Looking good. Terry has also learned ways that Shib might be usable with legacy REST API too...will apply to DSpace 6
  • Exposing Configuration values in REST API (early discussion PR from Terry)
    • https://github.com/DSpace/DSpace/pull/1928
    • How should these be exposed? Blacklist or whitelist?
      • We should use a whitelist to avoid accidentally exposing new config values that we don't want exposed
    • Andrea notes we also should use authorization here. Admins (or other groups) might be able to see some configurations that general public cannot
      • Tom: Maybe we can use Spring Security here
    • Whitelist should be configurable, possibly in Spring?  That way new third-party Plugins can update whitelist to expose their configurations as well
    • Eventually this may allow use to change configurations from the Admin UI. (may be post-DSpace 7 though)
    • ACTION: Terry will update ticket with discussion, and investigate implementations. May work with Tom.  

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

  • Luigi Andrea Pascarelli (4Science) has been working on more integration tests for Submission endpoint, and cleanup to align with Contract: https://github.com/DSpace/DSpace/pull/1929
    
    • ACTION: Tim will review once ready. Should be ready today/tomorrow.
  • Legacy REST API no longer working on "master" branch. PR to get it working again from Terry:
    • https://github.com/DSpace/DSpace/pull/1930
    • Tim notes this looks fine. However, we should log that there's a bug in the SolrLoggerUsageEventListener as a ticket.  We don't want this commented out for DSpace 7, as it essentially turns off usage statistics for this REST API
      • ACTION: Terry will log.  (Update: already done: 

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

        )
  • Question (Tom): Are we still "supporting" the Legacy REST API in DSpace 7?
    • YES. It will be released as part of DSpace 7, but will be deprecated.  It will then be removed in DSpace 8. This gives institutions time to migrate their tools/integrations to the new REST API. 
    • Note however that the Angular UI will NOT work with the legacy REST API.  So, everyone will be required to run the new REST API for Angular UI. They can just optionally choose to also install the deprecated, legacy REST API alongside that.
  • Are we still planning to version the REST API?
    • Yes, we should version the new API. It can be versioned separate from DSpace itself.
  • 4Science is currently working on MyDSpace (User Profile).
    • As discussed previously, MyDSpace should now be updated to use Solr / Discovery to locate Workspace Items and Workflow Items
    • This will require a new Solr Core, specific to searching Workspace/Workflow items.  It will also require modifications to the Discovery REST endpoint
    • Why do we need a new core?  Could we just use the main search core?
      • The main search Solr core (for Discovery) is very actively searched, as it is used on many public pages.  It is not updated frequently, but has high activity
      • For Workspace/Workflow items, the core will need to be updated frequently, but the number of items will be small (at any given time).  Because of the frequent updates, this could affect public browsing/searching if we were to do this in the main search core.
      • All agree this seems like a good approach
    • 4Science will be providing more info / documentation on this in progress effort in coming week(s)
• Next Meeting will be Thurs, Feb 1 at 15:00UTC in DSpace Meeting Room