Skip to end of metadata
Go to start of metadata


In 2018, we asked Keen Design to take a close look at the collaboration flows we need to support in the SCZ.  After interviewing a number of participants, they designed a number of flows that cover most of the use cases we would like to support in de SCZ.  This design was presented during a meeting on December 18th (meeting notes). The scenarios that were detailed in a design:


Scenario 1 - Login failed
View scenario

Scenario 2 - Request access
View scenario

Scenario 3 - Accept invitation
View scenario

Scenario 7 - Upload SSH key
View scenario

CO Manager

Scenario 4 - Create authorisation
View scenario

Scenario 5 - Granting access
View scenario

Scenario 6 - COU sends invitation
View scenario

Scenario 9 - Accept invitation
View scenario

SCZ Admin

Scenario 8 - Create collaboration
View scenario

(PDF-version in case the online scenario's don't work: scenario1-login.pdf, scenario2-request-access.pdfscenario3-accept-invitation.pdfscenario4-add-autorisations.pdfscenario5-granting-access.pdfscenario6-CO-sends-invitation.pdfscenario7-view-profile.pdfScenario8-Create-Collaboration.pdfscenario9-Accept admin-rights.pdf)

Keen did a presentation on their process and findings on dec 19th 2018 (sheets).

Data model

Based on these flows, the (preliminary) data model is as follows:

Which evolved to the following when we started building SBS ourselves (see below):

Development of new open source Collaboration Management System

In 2019, we have started a Proof of Concept (GitHub sources) to determine if it is viable to implement these above mentioned flows in a new Membership Management System that we've written from scratch. The user stories for this development can be found on Pivotal. This system is called SBS, an abbreviation for the Dutch words for collaboration management system.

SBS should be available online, but as we're developing, for other reasons, it might not be available (wink). But if you want to try: check out this DIY demo script: SCZ demo SBS . Some words before you dive in:

  • remember this is a PoC! WiP! It might crash. It might not yet have all the options we envision. Etc
  • to have a global understanding of the objects:
    • in our system we have 'organisations'. This is because some of our institutions want to see what collaborative organisations have been started that are the responsibility of that institution.
    • an organisation can have 1 or more collaborations
    • a user can join a collaboration by an invitation or by sending a join request
    • a collaboration has access to 1 or more services
    • access to a service is managed via authorisation groups. A member of a CO can be in 1 or more authorisation groups. An authorisation group can allow access to one or more services
    • for every service within the context of a CO, a user will have a user service profile that contains any CO specific service attributes
  • you can (try to) login with your own IdP, UnitedIdP, Orcid, Google or Microsoft ... you're admin and able to check out all currently available options, including impersonation. 
  • for platform admins, the system has an 'impersonation' option, which allows you to impersonate a user, a CO admin and an organisation admin
  • in many places an input-field functions in full text search mode, and often inputting a * will list all possible values
  • as it is a PoC & WiP, beware of what data you leave behind
  • at some point we will connect actual (test) services ... this documentation might not reflect the latest status (so maybe test services are connected)

Feel free to check it out. And let us know what you think, or when you have questions etc!

  • No labels