Page tree
Skip to end of metadata
Go to start of metadata


 from 15:00-16:00 UTC

Location: (Meeting ID: 502 527 3040).  Passcode: dspace

We will not be having a meeting on either Thursday, December 24 or 31 because of the Christmas Eve and New Years Eve holidays.  Developers who are working during the last few weeks of December will be expected to ask for feedback or code reviewers via Slack or GitHub when needed.

Tim is on holiday (completely offline) from Dec 23-Jan 3, returning on Monday, Jan 4.

Beta 5 Sprint : Ongoing


  • (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
    1. (30 mins) Template Row in a repeatable field is problematic:
      1. Repeatable fields "don't reflect the state of the form".  The first row (template row) is essentially a placeholder to add new values to a repeatable field (it was also added to avoid buttons on each value in a repeatable field – so it's the only HTML form element for that field)
      2. PR #960 improves the behavior of the submission form, but the repeatable field problem still remains.
      3. 4Science & Atmire teams should add brainstorms into the Ticket #971 prior to the meeting (ideally by Tues at the latest)
    2. Other topics (may be discussed if time allows):
      1. Updating the demo site(s) to use the domain/URL:  (This is requested by Steering in preparation for Beta 5)
      2. Restricted Bitstream access does not work when opening a new tab/window:
      3. Follow-up on "Usability issues when both Controlled Vocabulary & Configurable Entities enabled on a single field":
        1. Giuseppe added an alternative configuration ("onebox") when enabling both on the same field:
        2. Tim Donohue will look into the RegEx-based validation documented at
  • (30 mins) Planning for next week


7.0 Release Goals

These resources define the prioritization and general schedule we are working towards

Current Work

Project Board

DSpace 7.0 Beta 5 Project Board:

To quickly find PRs assigned to you for review, visit  (This is also available in the GitHub header under "Pull Requests → Review Requests"

Security / Performance Tests

Brainstorming options for security testing & performance testing.  How do we want to handle both of these prior to 7.0 final?

  1. Security Review/Scanning of pre-7.0:  See DSpace 7 Security Analysis 
  2. Performance testing of pre-7.0: See DSpace 7 Performance Analysis

Delayed / Needs Discussion

  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) ) : 
        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. (REST Contract) Edit Homepage News:
    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.