User roles and rights redesign

Discussion forum about Anuko Time Tracker
wrc
Posts: 278
Joined: Tue May 25, 2010 8:30 pm

Re: User roles and rights redesign

Post by wrc » Tue Feb 20, 2018 1:36 pm

Nik wrote:CUSTOM - a customized role for situations when roles above do not suffice. Having an integer rank, which determines how "manage_users" works for it, if assigned, compared with existing and custom roles. Has an arbitrary collection of permissions as set by group manager. Any number of custom roles can be defined.
Current roles already have an integer that can be used as a built-in rank. From initialize.php:

Code: Select all

// User roles.
define('ROLE_USER', 4);          // Regular user.
define('ROLE_CLIENT', 16);       // Client (to view reports and invoices).
define('ROLE_COMANAGER', 68);    // Team co-manager. Can do many things but not as much as team manager.
define('ROLE_MANAGER', 324);     // Team manager. Can do everything for a team.
define('ROLE_SITE_ADMIN', 1024); // Site administrator.
To keep things simple, a custom role may have a rank between 0-323, but not equal to 4, 16, 68 (for co-manager), or another number already linked with a custom role. Apparently, this puts a limit on the number of possible custom roles. My guess is that it will work for most installations.

Nik
Posts: 479
Joined: Wed May 26, 2010 5:55 pm

Re: User roles and rights redesign

Post by Nik » Wed Feb 21, 2018 3:09 pm

Below is a suggested structure for a new MySQL table top keep role information (custom and predefined). If this will not work for your situation please let us know.

Code: Select all

#
# Structure for table tt_roles. This table stores customized team roles.
#
CREATE TABLE `tt_roles` (
  `id` int(11) NOT NULL auto_increment, # role id
  `team_id` int(11) NOT NULL,           # team id
  `name` varchar(80) default NULL,      # role name - may be used to rename standard roles
  `rank` int(11) default 0,             # Role rank and identifier in comparison with other roles,
                                        # used to determine what "lesser roles" are
                                        # and also identifies a role within a team, used as role in tt_users.
  `rights` text default NULL,           # Comma-separated list of rights assigned to a role.
                                        # NULL here for predefined roles (4, 16, 68, 324 - manager)
                                        # means a hard-coded set of default access rights.
  `status` tinyint(4) default 1,        # role status
  PRIMARY KEY  (`id`)
);

# Create an index that guarantees unique active and inactive role ranks per team.
create unique index role_idx on tt_roles(team_id, rank, status);

bonnedav
Posts: 23
Joined: Thu Jul 20, 2017 5:17 am

Re: User roles and rights redesign

Post by bonnedav » Wed Feb 21, 2018 3:40 pm

The rank should only have to be unique per group. The ID field should be used to make each entry globally unique.

Nik
Posts: 479
Joined: Wed May 26, 2010 5:55 pm

Re: User roles and rights redesign

Post by Nik » Wed Feb 21, 2018 3:45 pm

bonnedav wrote:The rank should only have to be unique per group. The ID field should be used to make each entry globally unique.
Isn't this how role_idx guarantees the above already? Am I missing something?

Code: Select all

# Create an index that guarantees unique active and inactive role ranks per team.
create unique index role_idx on tt_roles(team_id, rank, status);

bonnedav
Posts: 23
Joined: Thu Jul 20, 2017 5:17 am

Re: User roles and rights redesign

Post by bonnedav » Wed Feb 21, 2018 4:09 pm

What is the difference between Id and role_idx? Do we need both? The post above you last one made it sound like the rank should be the unique id and I was saying that it should be separate. They are in you example.
EDIT: The table you made in you last commit has ID as the primary key. Everything with the table so far looks good to me.

Nik
Posts: 479
Joined: Wed May 26, 2010 5:55 pm

Re: User roles and rights redesign

Post by Nik » Wed Feb 21, 2018 4:27 pm

tt_roles.id - globally identifies a role for all groups on the entire Time Tracker server. Needed to edit a role.
tt_roles.rank - uniquely identifies either a standard role such as USER (4), CLIENT (16), CO-MANAGER (68), etc. or any of the custom roles defined within a single group.

Code: Select all

# Create an index that guarantees unique active and inactive role ranks per team.
create unique index role_idx on tt_roles(team_id, rank, status);
role_idx makes sure we have no duplicates for the same values of team_id, rank, and status. An active role is status 1. Deactivated role is status 0. Deleted role is status NULL and is not counted in an index restriction, so multiple values for NULL status are good.

I should probably improve the comment to make things a bit more clear.

bonnedav
Posts: 23
Joined: Thu Jul 20, 2017 5:17 am

Re: User roles and rights redesign

Post by bonnedav » Wed Feb 21, 2018 4:32 pm

When you delete a role it should remove the DB entry completely, not just set status to null. Unless you have an un-delete option, it just clutters up the DB. Same way with other tables as well.

bonnedav
Posts: 23
Joined: Thu Jul 20, 2017 5:17 am

Re: User roles and rights redesign

Post by bonnedav » Wed Feb 21, 2018 4:36 pm

role_idx still sounds like the same thing as role.id. maybe i am just misunderstanding? It looks fine in phpmyadmin so just stick with it.

bonnedav
Posts: 23
Joined: Thu Jul 20, 2017 5:17 am

Re: User roles and rights redesign

Post by bonnedav » Wed Feb 21, 2018 4:54 pm

Also, how deep can sub groups go? I think that when a manager creates a sub group he should be able to enable/disable sub group management for the new group's manager. Same with admins for top level groups. Groups created with multiteam mode should have sub groups disabled by default. They can be enabled by an admin.

Nik
Posts: 479
Joined: Wed May 26, 2010 5:55 pm

Re: User roles and rights redesign

Post by Nik » Wed Feb 21, 2018 6:07 pm

I improved commenting tt_roles table as follows.

Code: Select all

#
# Structure for table tt_roles. This table stores customized team roles.
#
CREATE TABLE `tt_roles` (
  `id` int(11) NOT NULL auto_increment, # Role id. Identifies roles for all groups on the server.
  `team_id` int(11) NOT NULL,           # Team id the role is defined for.
  `name` varchar(80) default NULL,      # Role name - custom role name. In case we are editing a
                                        # predefined role (USER, etc.), we can rename the role here.
  `rank` int(11) default 0,             # Role rank, an integer value between 0-324. Predefined role ranks:
                                        # USER - 4, CLIENT - 16, COMANAGER - 68, MANAGER - 324.
                                        # Rank is used to determine what "lesser roles" are in each group
                                        # for sutuations such as "manage_users".
                                        # It also identifies a role within a team (by its "rank").
                                        # Value of rank is to be used in role field in tt_users table,
                                        # just like standard roles now.
  `rights` text default NULL,           # Comma-separated list of rights assigned to a role.
                                        # NULL here for predefined roles (4, 16, 68, 324 - manager)
                                        # means a hard-coded set of default access rights.
  `status` tinyint(4) default 1,        # Role status.
  PRIMARY KEY  (`id`)
);

# Create an index that guarantees unique active and inactive role ranks in each group.
create unique index role_idx on tt_roles(team_id, rank, status);
bonnedav wrote:When you delete a role it should remove the DB entry completely, not just set status to null. Unless you have an un-delete option, it just clutters up the DB. Same way with other tables as well.
Although un-delete option is not available at the moment, the NULL status is needed at least in some installations for situations when users delete something by mistake. It gets an admin a chance to recover the data.
bonnedav wrote:role_idx still sounds like the same thing as role.id. maybe i am just misunderstanding? It looks fine in phpmyadmin so just stick with it.
One is a column in a table, another is an index on the entire table. UNIQUE refers to an index where all rows of the index must be unique. I used it here to prohibit creating active roles with the same rank. Used an index, because primary key is ID, which is used to find a record in a table. Perhaps there is a better way. Here we kind of use a rank as role id, which does not sound quite right, but makes things simple?
bonnedav wrote:Also, how deep can sub groups go?
As deep as one wants?
bonnedav wrote:I think that when a manager creates a sub group he should be able to enable/disable sub group management for the new group's manager.
Then go to role editor (when implemented, not available now) and remove the "manage_subgroups" right from their role?

bonnedav
Posts: 23
Joined: Thu Jul 20, 2017 5:17 am

Re: User roles and rights redesign

Post by bonnedav » Wed Feb 21, 2018 6:35 pm

Can the manager role be edited? Also different groups should be able to each have a role with the same rank. For example group1 has a custom role with rank 15 group2 should also be able to have a custom role with rank 15 and a different name, and have the id field used to differentiate them in the DB.

Nik
Posts: 479
Joined: Wed May 26, 2010 5:55 pm

Re: User roles and rights redesign

Post by Nik » Wed Feb 21, 2018 7:29 pm

bonnedav wrote:Can the manager role be edited?
I don't see why not. However, there is a danger of removing critical rights from this role such as "manage_users" and some others. Then people may end up unable to use the system when they remove a right by mistake. Perhaps, the root group manager role (top group in org) should always have all possible rights (except "administer_site", of course) . Need to think more about it.
bonnedav wrote:Also different groups should be able to each have a role with the same rank. For example group1 has a custom role with rank 15 group2 should also be able to have a custom role with rank 15 and a different name, and have the id field used to differentiate them in the DB.
No problems here.

bonnedav
Posts: 23
Joined: Thu Jul 20, 2017 5:17 am

Re: User roles and rights redesign

Post by bonnedav » Wed Feb 21, 2018 8:11 pm

There is also the problem that if you remove manage_subgroups from a sub-group's manager could they not just add it back? Maybe remove manage_subgroup from manager and create a new "root manager" with it? This role will be given to the manager of a top level (root) group and guarantee them all rights. Make this one not editable and make it's rank higher than manager so they can edit it. Then make managers unable to edit the manager role themselves. The "root manager" will be able to, Manage_subgroups, edit the manager role for subgroups, have all permissions on and access to all subgroups, grant back "manage_subgroups" to managers. Maybe make it intrinsic on subgroups to the parent group manager? I don't know. This needs more input and revision.

Nik
Posts: 479
Joined: Wed May 26, 2010 5:55 pm

Re: User roles and rights redesign

Post by Nik » Wed Feb 21, 2018 8:31 pm

bonnedav wrote:There is also the problem that if you remove manage_subgroups from a sub-group's manager could they not just add it back? Maybe remove manage_subgroup from manager and create a new "root manager" with it? This role will be given to the manager of a top level (root) group and guarantee them all rights. Make this one not editable and make it's rank higher than manager so they can edit it. Then make managers unable to edit the manager role themselves. The "root manager" will be able to, Manage_subgroups, edit the manager role for subgroups, have all permissions on and access to all subgroups, grant back "manage_subgroups" to managers. Maybe make it intrinsic on subgroups to the parent group manager? I don't know. This needs more input and revision.
Non editable ORG_MANAGER role makes sense to me. How about this:

Code: Select all

// Predefined user roles.
define('ROLE_USER', 4);          // Regular user.
define('ROLE_SUPERVISOR', 12);   // A person who has a small set of management functions in a group.
define('ROLE_CLIENT', 16);       // Client (to view reports and invoices).
define('ROLE_COMANAGER', 68);    // Team co-manager. Can do many things for a group but not as many as team manager.
define('ROLE_MANAGER', 324);     // Team manager. Can do most of things for a group.
define('ROLE_ORG_MANAGER', 512); // Non editable role of organization manager. Can do everything for organization top group and all subgroups.
define('ROLE_SITE_ADMIN', 1024); // Site administrator.
Values probably need an adjustment to allow more range where needed.

bonnedav
Posts: 23
Joined: Thu Jul 20, 2017 5:17 am

Re: User roles and rights redesign

Post by bonnedav » Thu Feb 22, 2018 8:12 pm

You need to make sure that if a perm is removed from a sub-group manager they can't add it to another role.
Also, this system works to let the top level manager edit sub group perms, but how would a level 2 manager remove a perm from the manager of one of there level 3 groups?
Also, i think you should re-split "manage_settings" into "manage_basic_settings" and "manage_advanced_settings" as well as "manage_features". basic settings would be things like "date format", "time format" ext... Advanced settings would be things like "name", "bcc" ext...

Post Reply