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


 from 14:00-15:00 UTC

Location: (Meeting ID: 502 527 3040).



Current Work

Legend for status icons

(blue star) = Highest Priority tasks (please prioritize these reviews/tasks over others). These are tasks with lots of dependencies

(error) = review done, changes were requested or bugs found.

(tick) = review done, approved.

(warning) = review done, merge conflict or other minor changes requests

1 APPROVAL = pull request only requires a single approval to merge.  This is generally reserved for PRs which are either smaller, obvious, and/or bug fixes with tests to prove they work.  

Tickets / PRs In Progress

  1. (Angular) Adding Accessibility via Travis CI (work in progress) (Lower priority)
  2. (warning) (Angular Bug) ( Art Lowel (Atmire) )
  3. (REST Contract) Edit Homepage news: (Ben Bosman  - has outstanding questions/comments) (Lower priority)
  4. (REST) DS-4043: Revisit the security layer of the submission  (work in progress) Andrea Bollini (4Science)
  5. (REST) Pagination bug with withdrawn items: (Dimitris Pierrakos , Ben Bosman - Feedback provided)

PRs Needing Review

  1. (REST Contract) Group and eperson management: (Tim Donohue - feedback provided,  Andrea Bollini (4Science) - (warning) feedback provided)
  2. (NEW) (REST Contract) Collection logo 1 APPROVAL (Andrea Bollini (4Science)Tim Donohue)
  3. (NEW) (REST Contract) collection item template 1 APPROVAL (Andrea Bollini (4Science)Tim Donohue)
  4. (REST) Authority control bugfixes ((tick)Tim DonohueGiuseppe Digilio (4Science)Andrea Bollini (4Science))
  5. (REST) Scripts and processes endpoint (Tim DonohueDimitris Pierrakos)
  6. (REST) DS-4337 implement bitstream-bitstreamformat relation endpoints (Tim Donohue REREVIEW Andrea Bollini (4Science) REREVIEW, Ben Bosman)
  7. (REST) Ds 4317 bundles in rest (Ben BosmanTim Donohue, Chris Wilper )
  8. (NEW) (REST) REST Projections "proof of concept": (Early Reviews welcome from all.)
  9. (NEW) (REST) Ds 4358 tests in modules (Tim Donohue , NEEDS SECOND REVIEWER)
  10. (Angular) Shibboleth integration support:  (Giuseppe Digilio (4Science) reviewed again fixed error with yarn start, Fernando FCT/FCCN, Paulo Graça - feedback provided)
  11. (Angular) forceBypassCache should be removed from the RequestService: ((tick)Art Lowel (Atmire) - approved again,  Giuseppe Digilio (4Science) )
  12. (Angular) Routing by handle and uuid: (Art Lowel (Atmire) - provided feedback, Giuseppe Digilio (4Science), Tim Donohue , Andrea Bollini (4Science) - might be able to help with pid endpoint)
  13. (NEW) (Angular) Tracking stats from the UI (Tim Donohue , NEEDS SECOND REVIEWER)
  14. (NEW) (Angular) Refactor object lists (Giuseppe Digilio (4Science)Tim Donohue)
  15. (NEW) (Angular) Disable e2e tests until docker issue is fixed 1 APPROVAL  (Andrea Bollini (4Science) will create a fix for main DSpace/DSpace repo)
  16. (Backend) dspace.bat file: 1 APPROVAL (Tim DonohueAlexander Sulfrian

PRs Merged this week!

  1. (tick) (REST) Issue when community has multiple dc.title values
  2. (tick) (REST) Spring security for createAndReturn with parent id
  3. (tick) (REST) DS-4359 add null check to getAllRelationshipTypes 
  4. (tick) (REST) DS-4360 fix searchevents link 
  5. (tick) (REST) (Entities) CSV Import fixes, improvements to entity validation:
  6. (tick) (Angular) Item-Collection Mapper: 
  7. (tick) (Angular) Collection pages WIP: 


  1. (Blocked PRs go here)

Delayed / Needs Discussion

  1. Managing Authorization info in Angular UIHow to pass Authorization rights (i.e. logged in user's access rights) from REST API to Angular?  See for example:
    1. Can this be achieved via passed HAL "_links" (e.g. the existence of an "edit" link in REST response means you must have Edit rights)?
    2. In July 25 meeting, we noted this probably cannot be resolved with just one simple solution. May need to look at different options for different scenarios
      1. Also likely to need to store/cache a user's Groups in UI layer, as some areas (e.g. Administrative) require knowledge of user group membership
  2. REST API Projections:  DS-3533 - Getting issue details... STATUS
    1. Early work begun at  Discussed in more detail in our Aug 22 meeting.  Overall, this approach seems like a good direction, need volunteers to move it forward.
      1. (discussion resumed by Andrea Bollini (4Science) could be relevant for the projection)
  3. Initial Performance Testing from Chris.
  4. (REST Contract) Edit Homepage News:
    1. Delayed until after Preview release. 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.
  5. Concurrency in DSpace 7 (or 8).  What do we want to do when multiple editors are editing the same object?  Needs further analysis regarding implementation details
    1. We've decided (in meeting on March 7, 2019) to use ETags to implement concurrency. REST Contract notes on ETags:
    2. ETags only update of the two fields match. If someone edits first, your edit would fail and you would get a fail response (422?)
    3. ETags seems to have broader support in other REST APIs.  Recommended also by both Art and Andrea.


  • Revisiting REST API Projections:
    1. Proof of concept PR:
    2. Slides that Chris Wilper presented
    3. Also some early "best practice" notes started at Guide to Resource Linking and Embedding (DRAFT)
  • Overall, team approves of this direction. We decided we might want to rework the proof of concept PR to be based on code already in `master` (currently it is based on the Bundles PR#2548 which is still under review)
    • We might think of doing proof of concept based on Item relationships, or maybe Community - Collection - Item relationships. These are both in master already, and an initial PR against either might be easier to review/approve more immediately than basing it off Bundles
  • All should review the initial PR and provide any other feedback.  Direction is good though.
  • Reviewing & scoping tasks flagged as "NEEDS MORE INFO" in Development Planning Spreadsheet
    • Only made it through first 3 in that spreadsheet
    • Tim will setup a Doodle poll for a separate meeting on this with Andrea, Art & Ben (minimally). Others are welcome too (get in touch).  Hopefully if we all review this spreadsheet we can quickly go through it in one meeting to determine how to scope each (and whether anything in the spreadsheet still requires deeper discussion).