...
We will create a new table in the Profile service which will contain the relationship between the TIS Username and the Trust ID .(Simon suggests Trust Code as unique and know by users)
Phase 1
Initially we will create the table and populate manually using scripts
...
As a purely tactical solution ahead of re-designing a more secure implementation of Roles and Permissions, we will extend use the existing solution with the Profile service and common components front end session code to write the Trust ID Admin role to the User cookie with the existing Roles and Permissions - no change should be required here.
Limiting access to TIS top menu sections
...
Trust ID can be established by navigating through a Person's placement to its Post, to its Site, to its Trust
Extend the Person List endpoint to check whether the TIS For all People endpoints - List and CRUD - when checking the logged in users authorisation against the profile service - if the user is a Trust Admin and if so retrieve their TrustIDAlternatively would we put the TrustID into browser local storage on logon so it can be checked directly from there in the Front End and passed to the Person List endpoint if present?, retrieve their Trust ID (change to profile service and how its called?)
The People List endpoint would then return a filtered list of apply an extra parameter on the select to further filter the returned People by joining to the PeopleTrust table on the TrustID
The people CRUD endpoints will validate that the person record being acted on is linked to the TrustID and accessible to the Trust Admin, if not return a permission error to the Front End
<<check comment about Sites can have a parent SIte or a Trust?>>We need to design and implement a way to check that a CRUD request from a Trust Admin user can only load existing details of a Person related to that Trust
Posts
Initially we need to performance test retrieving a list of Posts with an extra TrustID filter element to the SQL query - navigating from each Post to its Site, then to its Trust
If this isn't performant enough in realtime we will need to explore denormalising the TrustID into the Posts table or a linked table
We need to adapt the Posts List endpoint to enable the TrustID to be provided by the Front End
We need to design and implement a way to check that a CRUD request from a Trust Admin user can only load existing details of a Post related to that TrustSimilarly to People, we then need to obtain the Trust ID from the profile service during authorisation if the user is a Trust Admin
For the Post List we need to limit the results returned against any search or filter to those related to the Trust using the logic Post-Site-Trust
For the Post CRUD endpoints we need to deny the front end access to posts they don't have a link to
old content below here...
...