Difference between revisions of "Discussions"
(→Group Permissions) |
(→Group Permissions) |
||
| Line 11: | Line 11: | ||
# If a specific group is in v_menu_item_grous 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 permission view, add, delete set, any user on that group will get an error message "access denied" when he tries to access that menu option. | # If a specific group is in v_menu_item_grous 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 permission view, add, delete set, any user on that group will get an error message "access denied" when he tries to access that menu option. | ||
# 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 permission view, add, delete set. | # 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 permission view, add, delete set. | ||
| + | |||
| + | === Solutions === | ||
| + | * | ||
| + | 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 store 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_gropus 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 to every single tenant. Updates would also change 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 gruop that a local admin on a tenant wants to have. | ||
| + | |||
| + | * | ||
| + | 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. | ||
Revision as of 21:30, 12 November 2013
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 table is duplicated and linked with the new tennat 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). Database 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:
- If a specific group is in v_menu_item_grous 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 permission view, add, delete set, any user on that group will get an error message "access denied" when he tries to access that menu option.
- 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 permission view, add, delete set.
Solutions
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 store 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_gropus 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 to every single tenant. Updates would also change 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 gruop that a local admin on a tenant wants to have.
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.
