View ProjeQtOr On SourceForge.net
ProjeQtOr - Project Management Tool
Supportez nous sur Capterra
OIN - Open Invention Network
ProjeQtOr free project management software - More flexible permissions system and team membership - ProjeQtOr

Prochaines sessions de formation

Les prochaines formations et démonstrations sont ouvertes, inscrivez-vous rapidement !

 

Démonstration de ProjeQtOr

(gratuit, sur inscription)

Mardi 23 avril (10h30-12h)

Jeudi 16 mai (16h-17h30)

Jeudi 13 juin (10h30-12h)

 
 

Planifiez avec ProjeQtOr

3 et 4 avril (9h - 12h30)

 
 

Administrez avec ProjeQtOr

10 et 11 avril (9h - 12h30)

 

 

 
 

More flexible permissions system and team membership

More
03 Mar 2014 12:52 - 03 Mar 2014 12:52 #1 by Rexeh
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.
Last edit: 03 Mar 2014 12:52 by Rexeh.

Please Connexion or Create an account to join the conversation.

More
03 Mar 2014 13:04 #2 by Rexeh
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.

Please Connexion or Create an account to join the conversation.

More
03 Mar 2014 20:57 #3 by babynus

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

Babynus
Administrator of ProjeQtOr web site

Please Connexion or Create an account to join the conversation.

Moderators: babynusprotion
Time to create page: 0.029 seconds

Paramétrages de cookies

×

Cookies fonctionnels

Ce site utilise des cookies pour assurer son bon fonctionnement et ne peuvent pas être désactivés de nos systèmes. Nous ne les utilisons pas à des fins publicitaires. Si ces cookies sont bloqués, certaines parties du site ne pourront pas fonctionner.

Session

Veuillez vous connecter pour voir vos activités!

Autres cookies

Ce site web utilise un certain nombre de cookies pour gérer, par exemple, les sessions utilisateurs.