Currently, a user can only be part of one permissions group, which creates issues segmenting this system off.
Due to it's very nature, it holds dangerous information such as:
- How much is someone paid
- Number of key business reports
Perhaps we have:
- Low level employees
- Managers
- System Administrator
- Board Members
At the moment you would have to create 1 for each type... But perhaps, some people actually fulfil a "low level employee" / "manager" and "system administrator" role. So you end up having to create a new group and do all the permissions specific for that one user.
The relationship should become a 1 to many, where permissions are inherited/amalgamated into a single permission set on the fly.
This issue also extends to "teams" - That may be part of a bigger company, so affects comments and so forth.
At the moment, everyone must be bundled into "1" team such as:
Company
But in reality, "Company" may have many teams such as "Developers", "Testers", "Front-End Developers". If you break these out, you lose the ability to use things such as "Team only" comments on tickets, as anyone else will be unable to see them in the company. This leads you to have to affect the entire company onto a project for example, instead of perhaps affecting the "testing team" onto something.
I think the most complicated element of this... is how interpretation elements would be combined such as
Access mode to data
Specific access mode
Permission sets... the quick way would be to restrict it to merging:
Form access
Report access
But perhaps without the access modes, this would be not enough.
Currently, a user can only be part of one permissions group
Yes !
which creates issues segmenting this system off.
Not imo
Due to it's very nature, it holds dangerous information such as:
- How much is someone paid
- Number of key business reports
It only depends on how you configure access rights.
For instance, if you don't want to give acces to cost datato project leader, you just have to removthis access (in specific access rights)
For reports, you can define for each report which profile can hace access.
Perhaps we have:
- Low level employees
- Managers
- System Administrator
- Board Members
This is a good beginig to set ... profiles.
At the moment you would have to create 1 for each type... But perhaps, some people actually fulfil a "low level employee" / "manager" and "system administrator" role. So you end up having to create a new group and do all the permissions specific for that one user.
Yes, but I still don't see an issue : you get complex management for complex need...
The relationship should become a 1 to many, where permissions are inherited/amalgamated into a single permission set on the fly.
No.
Much too complex and dangerous.
This way you're almost sure you will expose unwished data to someone.
This issue also extends to "teams" - That may be part of a bigger company, so affects comments and so forth.
At the moment, everyone must be bundled into "1" team such as:
Company
But in reality, "Company" may have many teams such as "Developers", "Testers", "Front-End Developers". If you break these out, you lose the ability to use things such as "Team only" comments on tickets, as anyone else will be unable to see them in the company. This leads you to have to affect the entire company onto a project for example, instead of perhaps affecting the "testing team" onto something.
This really look like Ticket #987