Discussions

Group Permissions

The way group permissions work today in FusionPBX should/must be improved. This discussion section will try to get the input from everyone interested on contributing to make group permissions better.

With the latest FusionPBX, from now on fusion, everytime a new tenant is created all the information on the v_groups DB table is duplicated and linked with the new tenant uuid (domain_uuid). The table v_group_permissions tells which permissions are enabled for a specific group (Ex: view, add , delete options on one app). DB table v_menu_item_groups is responsible for the definition of which menu a group can see/access. If a group isn't in this table, it won't be able to see/access the menu.

The current approach has 2 problems:

1. If a specific group is in v_menu_item_groups DB table, it will be able to see/access the menu. However if the same group doesn't exist in DB table v_group_permissions, with permissions view, add, delete set, any user on that group will get an error message access denied when he tries to access that menu option.
2. If a specific group isn't in the DB table v_menu_item_groups, any user in that group won't be able to see/access the menu, even if the group is in DB table v_group_permissions with permissions view, add, delete set.

Solutions:

• Use a new DB table for default permission groups

One way to improve the current behaivor could be by using a new DB table that would store the so called "default permissions groups". The table would have a structure quite similar to the current DB table v_default_settings but without relation to any tenant (domain_uuid).

The DB table v_groups would still store the per tenant permission groups. Keeping things like this won't change much the current logic in fusion because DB tables v_group_permissions and v_menu_item_groups currently use group_name (superadmin, admin, user, ...) instead of group_uuid.

Following this approach, everytime someone wants to create a new global permissions group it would make things easier to get that specific set of permissions available on every single tenant once. Updates would also be available across all tenants once.

The global permission groups could be listed in read only mode on each tenant, if an admin wants to copy and duplicate that set of permissions as a template for a new custom group that he wants to have on his own tenant.

• Another approach to solve the problem would be the definition of a relationship between tenants, as father/child.

If we say that a tenant has a parent, it would then inherit the group permissions from the parent.