This epic describes the rationale for Semantic Treehouse (STH) related development activities regarding fine grained access control. ## Context Semantic Treehouse started as an online platform for publishing message models (like the SCSN standards). Core functionalities provided to end users were viewing the message models and related specifications, including codelists, business rules and technical schemas. Furthermore the platform provided integrated validation support for end users to test their implementations. The specifications were maintained by a single or small group of maintainers, usually a standardization body and/or community manager. These maintainers have domain expertise and technical expertise on (semantic) modelling and in-depth knowledge of how the STH platform is used. A surrounding group of experts, often a working group, is involved in creating and maintaining these specification by means of providing input and review. This happens both during work group meetings and online by means of submitting issue and review comments. There was no need for working group members to have access rights to edit/update the specifications directly, this was the responsibility of the maintainers. For many years, this allowed us to focus our development efforts on end user experience and adding advanced features like the validator and wizard. ## Growing use of STH brings new challenges We see a couple of changes with the growing interest and use of Semantic Treehouse: 1. A larger group of people in involved in maintaining a larger scope of specifications; more working groups are working on more sets of specifications separately. 2. There is the need to delegate and give maintainer access to more involved people given the increasing scope of many standardization and data sharing initiatives; including the different projects/work packages under the NEXTGEN program. 3. There is lower in-depth knowledge of how the STH platform functions and what you can and cannot do without accidentally impacting other specification. This is due to the increasing scope and group of involved people. This means that there is not a small group of people anymore that oversees everything and can guard the consistency and prevents accidents (like unintended edits or deletes) by means of their processes. STH needs to build support for this in the platform itself. Furthermore, the absence of a notification system (see &13) makes it hard for the involved people to know what is happening in the platform. ## Fine grained access control Currently a user can get the following roles in the platform: _User_, _Reviewer_, _Maintainer_, _Account manager_, _Administrator_. This role and the related access control applies to the whole environment, i.e. to the entire content. Only viewing access can be limited to a set of specifications. Currently, core concepts in STH are scoped/grouped according to the following hierarchy: * STH environment * Top level projects (no owner) * Specifications * Groups * Projects * Specifications * Accounts * Projects * Specifications * Codelists * Message mappings * Business rules * Issues * Organizations * Representatives In order to address the challenges described above, we need to implement a more fine grained access control. This means that roles with its related access rights are scoped when given to a specific user. So instead of having the maintainer role for all specifications in the platform, you can get the maintainer role for a specific project and only have edit rights for the specifications under that project. The new hierarchy need to look like: * STH environment * ~Communities~ * Groups/communities * Subgroups (isa Group) * Members * Projects * Specifications * Issues * Organizations (isa Group?) * Representatives * Projects * Accounts * Projects This also requires that the following concepts are scoped to projects by means of subclassing a specification * Codelist --> subclass of Specification (like Taxonomy) * Message mapping --> idem * Business rules --> a new specification type is needed to bundle business rules