Difference between revisions of "Discussions"

From FusionPBX
Jump to: navigation, search
(→‎Solutions)
(→‎Solutions:)
 
(5 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
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.
 
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).
+
With the latest FusionPBX, from now on fusion, everytime a new tenant is created all the information on the <code>v_groups</code> 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).
+
The table <code>v_group_permissions</code> 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.
+
DB table <code>v_menu_item_groups</code> 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:
 
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 is in <code>v_menu_item_groups</code> DB table, it will be able to see/access the menu. However if the same group doesn't exist in DB table <code>v_group_permissions</code>, 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.
−
# 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 <code>v_menu_item_groups</code>, any user in that group won't be able to see/access the menu, even if the group is in DB table <code>v_group_permissions</code> with permissions view, add, delete set.
  
−
===== Solutions =====
+
===== 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.
+
* 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 <code>v_default_settings</code> but without relation to any tenant (''domain_uuid'').  
 +
:: The DB table <code>v_groups</code> would still store the per tenant permission groups. Keeping things like this won't change much the current logic in fusion because DB tables <code>v_group_permissions</code> and <code>v_menu_item_groups</code> 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 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.
+
* 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.

Latest revision as of 21:58, 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 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.
Retrieved from "http://wiki.fusionpbx.com/index.php?title=Discussions&oldid=2864"