Versions Compared

Old Version 18

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version Current

changes.mady.by.user Tim Donohue

Saved on

Key

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

...

  1. Submission & Workflow UI / backend
  2. Configurable Entities (from DSpace 7 Entities Working Group (2018-19))
  3. Upgrading Solr Server for DSpace (not required for Preview, as there's no user facing features. However, the earlier we feel comfortable merging this effort the better)

Notes

  • Discussion topics
    • Discussion of deletion of EPeople for GDPR compliance (from Pascal): https://github.com/DSpace/DSpace/pull/2229. NOTE: item.getSubmitter() will return null if EPerson deleted.
      • Consensus that there's only two viable approaches... Either we delete the EPerson entirely (see Pascal's PR), or we use a "ghost user" approach (a special user account which is linked to Items where submitter/Eperson was deleted)
      • Lieven notes concerns about not catching all the possible NullPointerExpections if we delete EPerson entirely. We have some tests, but we aren't sure we have all scenarios tested.
      • Pascal notes that it would be a community/team effort to find & fix any that are not already fixed
      • Tim notes our new test driven development processes should help us to find these issues more quickly.  Community Testathon can clean up the rest.
      • Andrea notes if we go with delete Eperson approach, we should add integration tests to REST API and Angular to check for possible problems (especially around null submitter)
        • Tim volunteers to help with Integration Tests on REST API
        • We'd likely need more help on Angular side integration tests
      • Tim is concerned with "ghost user" approach, as it'd be a specialized EPerson account that would need to be treated differently than all other EPersons.  Unclear how much effort that would be, and whether that causes additional complications.
      • Not a clear consensus on whether we want to delete EPerson or use "ghost user" – different individuals favor different approaches.  However, there's no strong objections to either approach from anyone – just personal concerns expressed.
      • FINAL DECISION: Since we have a PR#2229 and no one has strong objections, let's move it forward as-is.  Let's work together to create the missing integration tests (Tim will help) and add comments noting any missing use cases / scenarios where a Null EPerson could be a problem. That way we can build out integration tests.
    • Skipped discussion of Concurrency in DSpace 7. Will pick that up next week
    • Discussion of Edit Homepage News: https://github.com/DSpace/Rest7Contract/pull/45
      • Tim wanted more details on the proposed approach to use Bitstreams to store the Homepage news
      • Andrea said this could be metadata, like Community/Collection news
      • Tim agrees. We should consider using the Site object to store metadata for homepage news / logos, in the same way that these are stored on individual Community & Collection objects.
      • Lieven & Ben note they will consider this internally & bring ideas back for discussion next week