Page History

...

1. 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 
        1. Art Lowel (Atmire) : I don't see any immediate issues with the current set of features, but I would prefer a consistent naming scheme. I'd use canDoSomething for everything
        2. Tim Donohue added possible renames of these features based on Art's idea (see cell comments in spreadsheet).  I like the "can[DoSomething]" naming scheme as well.
2. Initial Performance Testing from Chris.  Needs revisiting / retesting prior to 7.0. 
   1. https://cwilper.github.io/dspace-perftest/
   2. These performance tests were run prior to the work on "projections" (to limit the data returned by the REST API).  Therefore, it is likely performance is much improved, but needs verification testing.
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.

Notes

• Follow-up to Submission form conceptual design. Review & Discuss Atmire plan
  • All generally agree with approach laid out in https://github.com/DSpace/dspace-angular/issues/818#issuecomment-669765211
  • Andrea notes that the PATCH request fields should match the response fields.  See https://github.com/DSpace/dspace-angular/issues/818#issuecomment-685994648
  • Tim adds very minor feedback.  Doesn't like the "type='plain-metadata-value'" as that's a rather long type name.  Is it possible to shorten to "type='metadatavalue'"?   Or is there a reason why we need to note this is "plain" metadata?
  • All agree this is lower priority for 7.0, as the features "work" (once Controlled Vocab PR is merged, and it's close).  So, this work is essentially a major refactor to make the relationships/entities code easier to maintain in the long run, and align it so that everything in the Submission Process goes through the WorkspaceItem and WorkflowItem.  The features will work in 7.0, but in 7.1 we'll refactor/clean them up.
  • NEXT STEPS
    • Ben Bosman will create a REST Contract PR to describe necessary changes (based on the approach he already laid out, with feedback from others)
    • Tim Donohue will create two new tickets for 7.1
      • A ticket for the REST API implementation, copying over Ben's estimates & eventually linking to the REST Contract PR.
      • A ticket for the Angular implementation. Art Lowel (Atmire)will add details of some necessary changes he's aware of, along with a rough estimate of work.