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  table is duplicated and linked with the new tenant uuid (domain_uuid). The table  tells which permissions are enabled for a specific group (Ex: view, add, delete options on one app). Database table  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   DB table, it will be able to see/access the menu. However if the same group doesn't exist in DB table , 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 , any user in that group won't be able to see/access the menu, even if the group is in DB table   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  but without relation to any tenant (domain_uuid).
 * The DB table  would still store the per tenant permission groups. Keeping things like this won't change much the current logic in fusion because DB tables   and   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.
 * Updates would also be available across all tenants at the same time.
 * 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 the problem would relate tenants by father/child.
 * If we say that a tenant has a parent, it would inherit the group permissions from the parent.