User roles and rights redesign

Discussion forum about Anuko Time Tracker
Nik
Posts: 427
Joined: Wed May 26, 2010 5:55 pm

User roles and rights redesign

Post by Nik » Fri Feb 16, 2018 10:31 pm

This thread is to hear your thoughts on user roles and rights (or are they "permissions"?) redesign in Time Tracker.

Current problems:

1) Users are limited to one group, which is not enough for a mid-size organization.
2) User rights is currently a bit mask. It is obvious that we will run out of bits at some point after introducing more rights.

Currently suggested direction to solve both problems:

- Introduce a tree-like structure for organizations, with groups of 1 or more users possibly containing other groups in a parent-child relationship. Think about tt_teams table having org_id, unit_id, and parent_unit_id instead of just one id field,
- Have rights as an array of strings instead of bits in a number. For example:

USER - a regular user in a group without any management rights. Primary function is data entry and viewing own data.

"track_own_time" - can track own time in Time Tracker.
"track_own_expenses" - can track own expenses in Time Tracker.
"view_own_reports" - view own reports.
"view_own_charts" - view own charts.
"view_own_projects" - view assigned project names and their descriptions.
"view_own_tasks" - view tasks for assigned projects and their descriptions.
"manage_own_settings" - edit own settings such as account password.
"view_users" - view user names and roles in a group.


CLIENT - when Clients plugin is enabled, a Client (which is external to a group) can be provided with a login to view own data such as reports, charts, and invoices.

"view_own_reports" - view own reports. In context of a client it means reports for this particular client. Note that clients do not have the "track_own_time" right but can view what is entered into the system by other users and is associated with a specific client.
"view_own_charts" - view own charts. In context of a client it means charts for this particular client.
"view_own_invoices" - view invoices issued for client.
"manage_own_settings" - edit own settings such as login, password, email, etc.


SUPERVISOR - a person who has a small set of management functions in a group. Has all of USER permissions plus the following.

"track_time" - can track time on behalf of lower roles.
"track_expenses" - can track expenses on behalf of lower roles.
"view_reports" - can view reports for lower roles.
"view_charts" - can view charts for lower roles.
"view_own_clients" - view clients assigned to own projects.
"override_punch_mode" - can input any start and finish times for lower roles (not self).
"override_own_punch_mode" - can override punch mode for self.
"override_date_lock" - can override date lock for lower roles.
"override_own_date_lock" - can override date lock for self.
"swap_roles" - succession mechanism, allows a person to swap roles with someone having a smaller role rank and a smaller set of rights.
"approve_timesheets" - reserved for future approval workflow (not implemented at this point).


CO-MANAGER - a person with an extended set of management functions, who is helping a group manager with most of the work. Has all of SUPERVISOR permissions plus the following.

"manage_own_account" - can modify own login, name, and email.
"manage_users" - can add, modify, delete, and assign roles to users with role's rank less than self.
"manage_projects" - full access to project management.
"manage_tasks" - full access to task management.
"manage_custom_fields" - full access to custom field management.
"manage_clients" - full access to client management.
"manage_invoices" - full access to invoice management.
"override_allow_ip" - override access restriction based on IP address in group settings.
"view_all_reports" - can view reports for all members of the group including users with higher rank.


MANAGER - a person with a full set of permissions to a group and the entire tree of its subgroups. Has all of CO-MANAGER permissions plus the following.

"manage_features" - enable or disable plugins (features) for a group.
"manage_basic_settings" - manage basic group settings such as language, currency, date and time formats.
"manage_advanced_settings" - manage advanced group settings such as team name, bcc, plugin options, etc.
"manage_roles" - create, modify, and delete roles (including custom roles) with rank less than self. Able to add permissions that they have themselves.
"export_data" - export group and all subgroups data to an XML file.
"manage_subgroups" - add, modify, and delete subgroups. Essentially, it gives a capability to create subgroups and assume group manager role in there and all subgroups below.


TOP_MANAGER - intrinsic, non-editable role for a general manager in an organization (root manager) with all possible rights in all groups. Is assigned to a person who creates the organization. Has all MANAGER rights plus the following.

"delete_group" - can delete a group and all subgroups.

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.

ADMIN
"administer_site" - administer a site as a whole.

Changing manager - see "swap_roles" in SUPERVISOR role.
Last edited by Nik on Wed Apr 11, 2018 2:24 pm, edited 85 times in total.

dalescott
Posts: 58
Joined: Fri Apr 21, 2017 2:53 pm
Location: Calgary, Alberta, Canada
Contact:

Re: User roles and rights redesig

Post by dalescott » Sat Feb 17, 2018 6:59 pm

A tree structure will be needed to follow functional supervisor/subordinate authority to determine who is responsible for approving who’s time sheet, and to support temporary delegation of authority from a supervisor to a subordinate (e.g. for when a supervisor goes on vacation). It may be convent to always allow a supervisor’s supervisor to do anything their subordinate can do (e.g. to approve the subordinate’s subordinate’s timesheets if the subordinate e.g. called in sick the day timesheets need to be approved.

However, the strategy must also support sideways delegation of authority to a sibling supervisor (if I was, for example, the Electronics Engineering Manager and got the Software Engineering Manager to approve my subordinat’s timesheet when I went on vacation).

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

Re: User roles and rights redesign

Post by Nik » Sat Feb 17, 2018 7:20 pm

We are not doing approval workflow now. Approval is separate from roles and permissions.

A group manager can assign roles. So, assuming there are roles for what you need, a manager (or whoever is given the right) can assign / reassign.

To keep this realistic, the scope of this change should be relatively small, as multiple groups alone introduce a significant complication to the existing stuff.

What we need is to design roles nicely, so that we don't have a mess, and there is some flexibility. The current list above is not good enough.

dalescott
Posts: 58
Joined: Fri Apr 21, 2017 2:53 pm
Location: Calgary, Alberta, Canada
Contact:

Re: User roles and rights redesign

Post by dalescott » Sat Feb 17, 2018 7:32 pm

Hi Nik, I agree roles and rights are not directly associated with approval workflow, but I expect approval workflow will take advantage of the underlying roles and rights functionality, so it may be useful to at least consider the two together (or at least that was my line of thinking). Cheers.

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

Re: User roles and rights redesign

Post by Nik » Sat Feb 17, 2018 8:53 pm

I added "approve_timesheets" to the CO-MANAGER collection of permissions and also added some // TODOs to the list - to the parts that look questionable to me at this point.

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

Re: User roles and rights redesign

Post by bonnedav » Sat Feb 17, 2018 10:24 pm

Here is what I think:

CLIENT
"view_own_data"

USER
"data_entry"
"view_own_data"
"view_users" // maybe.

SUPERVISOR - all of USER plus the following.
"view_users" //if not given to USER above.
"on_behalf_data_entry" - can enter data on behalf of lower roles.
"view_group_data" - can view data for lower roles.
"adjust_time" - can change past time entries for lower roles.
"override_punch_mode" - can input any start and finish times for lower roles.

CO-MANAGER - all of SUPERVISOR plus the following
"adjust_own_time" - can change own past time entries.
"override_own_punch_mode" - can input any start and finish times for themselves.
"manage_users" - //should only be able to mod/del users below them. should also be able to assign user roles lower then there own.
"manage_projects"
"manage_tasks"
"manage_clients"
"manage_client_users" - can assign client roles and manage users with client roles.
"manage_invoices"

MANAGER - all of CO-MANAGER plus the following.
"manage_group_settings" //maybe group settings should be on there own page?
"manage_roles"
"export_data"
"manage_subgroups"

Any role that has "data_entry" is a user role. any role that does not is a client role.
A user role can view there own time data. Can be assigned by the "manage_users" right.
A client role makes a user tied to a client and can only see data from that client. Can be assigned by the "manage_client_users" right

I also think that the options in the config file should be moved to the admin panel. As well as the "Clean up DB from inactive teams" option form dbinstall.php.

CO-ADMIN
"administer_site" - marks the role as and admin role and not a team role so they go to the admin panel on login.
"manage_teams" - add, modify and delete teams as the admin panel does now.
"import_teams" - can import teams form other Time Tracker sites. // maybe have a check box to enable/disable this per CO-ADMIN?

ADMIN - all of CO-ADMIN plus the following.
"manage_admins" - add, modify, delete CO-ADMINS.
"manage_site_settings" - modify global settings form the admin panel.
"cleanup_db" - use the "Clean up DB from inactive teams" option on the admin panel.

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

Re: User roles and rights redesign

Post by Nik » Sun Feb 18, 2018 5:24 pm

Thanks for the input. I edited the list to include some suggestions.

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

Re: User roles and rights redesign

Post by bonnedav » Sun Feb 18, 2018 5:47 pm

Instead of having each custom role based on a default role, you can let the manager assign a "rank" value to each role. Then just compare that value. The default roles should be editable per team as well. Maybe the default roles should just be what is filled in to a team's custom role table upon team creation and are treated the same as custom roles. Maybe also rename USER to MEMBER? And just wondering, where did "view_users" go?
Also, we can worry about the admin stuff after the team role stuff is done, i just put it in there as something to think about.

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

Re: User roles and rights redesign

Post by bonnedav » Sun Feb 18, 2018 7:15 pm

I also think that you should have "edit_basic_settings" and "edit_advanced_settings" but give them both to manager by default, just to have more flexibility with custom roles.

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

Re: User roles and rights redesign

Post by bonnedav » Sun Feb 18, 2018 7:51 pm

Maybe the way teams and managers are associated is what needs rethinking. Maybe make it so a manager can transfer management. And allow an admin to force a transfer as well.

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

Re: User roles and rights redesign

Post by bonnedav » Sun Feb 18, 2018 7:55 pm

That is why there should be multiple admin accounts.

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

Re: User roles and rights redesign

Post by Nik » Sun Feb 18, 2018 8:00 pm

I added some more permissions to the list and also some // TODOs, but apparently, the entire thing needs more reviews and adjustments.

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

Re: User roles and rights redesign

Post by bonnedav » Sun Feb 18, 2018 8:00 pm

Maybe have a system of succession where a manager can mark a Co manager and if the manager does not login for x days IE Dead than there roles will auto swap. Also if nobody has access to an admin account then they have bigger problems.

Uashbjo
Posts: 13
Joined: Tue Oct 24, 2017 9:41 pm

Re: User roles and rights redesign

Post by Uashbjo » Mon Feb 19, 2018 2:12 pm

Could there be a SuperManager that could have the manager's rights but for multiple teams without being an admin?

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

Re: User roles and rights redesign

Post by Nik » Mon Feb 19, 2018 2:51 pm

Uashbjo wrote:Could there be a SuperManager that could have the manager's rights but for multiple teams without being an admin?
That is what MANAGER role already has: "manage_subgroups" - add, modify, and delete subgroups. Essentially, it gives a capability to create subgroups and assume group manager role in there and all subgroups below.

In theory, create a tree for the entire org and manage it using one manager account for a top group.

Post Reply