(BEFORE MEETING IN #dev-sprint) 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
(20 mins) Submission form conceptual design: Originally designed to only touch WorkspaceItem and WorkflowItem, the recent changes in PR#541 now touch the Item object (and cause issues for other PRs). Giuseppe Digilio (4Science)added a ticket to describe the problem & provide a proposed solution: https://github.com/DSpace/dspace-angular/issues/818
Do we agree that the submission forms should ONLY touch WorkspaceItem and WorkflowItem? (NOTE: This is similar to behaviors in DSpace v6, where submission forms never interacted with the Item directly, but always worked through these "wrapper" objects)
Any additional ideas/concepts we need to clarify in Submission process design? (This is an opportunity to document our assumptions/design for this Submission process, so that we can work from a common idea.)
(10 mins)Security issues in Processes REST endpoint: Some CLI flags should never be usable via the REST API (e.g. `--eperson`). We should find a way to either disable these flags automatically via the REST API, or perhaps a way to configure (per script) which flags are "CLI-only".
This same issue has already appeared in multiple scripts (see links below) and for multiple CLI flags. Unfortunately, some CLI flags become a security issue when available on REST, but they arenota security issue via CLI.
To quickly find PRs assigned to you for review, visit https://github.com/pulls/review-requested (This is also available in the GitHub header under "Pull Requests → Review Requests"
Delayed / Needs Discussion
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)
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
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.
Initial Performance Testing from Chris. Needs revisiting / retesting prior to 7.0.
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.
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.
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
Timeline for this is uncertain. Possibly in 7 or 8. May depend on how/whether it can be scoped.