Permission system

Development related discussion.
Post Reply
User avatar
Jack
Advanced Member
Posts: 666
Joined: Fri Mar 27, 2009 7:37 pm
Location: Australia

Permission system

Post by Jack » Mon Feb 13, 2012 3:38 pm

I was trying to figure out how I would do the permission system in 3.0, then realised that I had already had a system created but in another project.



I'll be basing the new permissions of that system for Traq 3.0, and it will work something like this:


Code: Select all


// Fetch the permissions for the project and users group

Check if the permissions table contains a row with project_id of 1 and group_id of 3

    Return permission set

Otherwise

    Return permission set with project_id of 0 and group_id of 3



// Check if the user has permission to create a new ticket

if ($project->permission(current_user()->group_id, 'create_tickets')

   // Show new ticket page.



What do I mean by get the permission set with the project_id of 0?



Projects don't need to set permissions for user groups. Think of it like a forum and you have inheritance.



If the project doesn't have it's own permissions for a specific group, it will inherit them from the default permissions for that group.

User avatar
arturo182
Advanced Member
Posts: 151
Joined: Mon Mar 22, 2010 10:28 am
Contact:

Re: Permission system

Post by arturo182 » Mon Feb 13, 2012 9:03 pm

I also think that maybe you could do something else than creating columns for every permission.



Maybe permission could be stored in the db as a "binary" string, for example "01110", 0 on the 1st place means that the group can't create tickets, 1 on the 2nd place means it can update tickets. This way you can easily add new permission, but when you look at the records in the db you won't be able to see which group has what permissions unless you memorized which index is what permission.



An alternative could be using alphanumeric characters to express permission, for example "bcd", the string contains "b" so this group can update tickets, but it doesn't contain "a" so it can't create tickets. You would have a limited number of permissions (0-9 + A-Z + a-z) but it would be easier to remember which one is which.



In C++ I would create and enum for every permission and then do something like:

Code: Select all

if (current_user()->hasPermission($project->id(), Permissions::CreateTickets))


You can achieve pseudo enums in PHP ( http://stackoverflow.com/questions/254514/php-and-enums ) so maybe you can do it this way.
Last edited by arturo182 on Mon Feb 13, 2012 9:03 pm, edited 1 time in total.

User avatar
Jack
Advanced Member
Posts: 666
Joined: Fri Mar 27, 2009 7:37 pm
Location: Australia

Re: Permission system

Post by Jack » Mon Feb 13, 2012 9:25 pm

hmm, there are some advantages but also some problems.



The DB size will probably be smaller, but what if you have a plugin that wants its own permissions, the author has to check if any other plugin is using the same character they want to use.



Also what about when the user removes the plugin, the permissions remain in the DB, cluttering things up.



With columns a plugin can add its permissions on install and remove them on uninstall.



I will think about it some and see if there is a way for it to work.

User avatar
arturo182
Advanced Member
Posts: 151
Joined: Mon Mar 22, 2010 10:28 am
Contact:

Re: Permission system

Post by arturo182 » Mon Feb 13, 2012 11:10 pm

I thought about plugins adding/removing their own columns but in other thread you mentioned that you don't like the idea of plugins copying files around so I thought same thing goes for the db.



Another idea is to have a "permissions" table with group_id and permission_name. This way plugins would just insert/delete rows and checking permissions would be easy. The only downside is having another table.

User avatar
Jack
Advanced Member
Posts: 666
Joined: Fri Mar 27, 2009 7:37 pm
Location: Australia

Re: Permission system

Post by Jack » Tue Feb 14, 2012 1:50 am

Plugins copying files around all over the place into who knows what directories can be messy, but a few columns in the database should be fine.

User avatar
arturo182
Advanced Member
Posts: 151
Joined: Mon Mar 22, 2010 10:28 am
Contact:

Re: Permission system

Post by arturo182 » Tue Feb 14, 2012 1:58 am

I have a question, are you planing per-project permissions or just global groups, for example if I'm in a group that has the permission to delete comments can I delete comments in any project or is the group tied to a specific project?

User avatar
Jack
Advanced Member
Posts: 666
Joined: Fri Mar 27, 2009 7:37 pm
Location: Australia

Re: Permission system

Post by Jack » Tue Feb 14, 2012 11:18 am

Per-project permissions.



You will be able to set different permissions for each project and group.



Here's an example of the possible database structure for it.

Code: Select all


group_id  |  project_id  |  create_tickets  |  update_tickets  | ...

   1     |      0      |         1        |         1         |

   2     |      0      |         1        |         1         |

   2     |      1      |         1        |         0         |



The rows with project_id == 0 is the default/global permission for that group.



As you can see, there are two default/global permission rows, these will always be in the database, however we wanted to stop the group with the id of 2 from updating tickets on project the project with the id of 1, when we set the permissions for that group the system inserted the row.



So when the system fetches to permission set for that group and project, it will check for the custom permissions first, then fallback to the default/global permissions.
Last edited by Jack on Tue Feb 14, 2012 11:39 am, edited 1 time in total.

User avatar
Jack
Advanced Member
Posts: 666
Joined: Fri Mar 27, 2009 7:37 pm
Location: Australia

Re: Permission system

Post by Jack » Fri Mar 16, 2012 9:14 pm

I've started working on the permission system and decided to change how the permissions are stored.



Permissions are stored in their own row, instead of group-per-row, there is also two sets of default permissions.



This may sound confusing, but it's actually simple.



There are the defaults for all groups and projects, then the defaults for specific groups and all projects.



Image



After that comes the per-group-and-project permissions.



This system was designed to allow plugins/addons to easily add their own permissions and to allow for even more inheritance for permissions.
You do not have the required permissions to view the files attached to this post.
Last edited by Jack on Fri Mar 16, 2012 9:14 pm, edited 1 time in total.

User avatar
Jack
Advanced Member
Posts: 666
Joined: Fri Mar 27, 2009 7:37 pm
Location: Australia

Re: Permission system

Post by Jack » Wed Mar 21, 2012 10:28 pm

Been thinking about the permission management page, I want it to be clean and simple.



The best way seems to be a select box with the three options for the permissions (Inherit, Yes, No) as the radio buttons will take up too much room:



Image



But instead of having the permissions as the columns and groups as the rows, the page will look pretty much like:



Image
You do not have the required permissions to view the files attached to this post.
Last edited by Jack on Wed Mar 21, 2012 10:42 pm, edited 1 time in total.

User avatar
arturo182
Advanced Member
Posts: 151
Joined: Mon Mar 22, 2010 10:28 am
Contact:

Re: Permission system

Post by arturo182 » Thu Mar 22, 2012 9:33 pm

Maybe "Allow" and "Deny" instead of "Yes" and "No".
Traq, yo!

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest