Sugeriría crear una serie de grupos de usuarios en su base de datos, cada uno de los cuales tiene uno o más niveles de cuenta de usuario, asignar un número entero como un valor jerárquico al grupo y luego hacer lo mismo con la cuenta individual niveles dentro del grupo, algo como esto (esta es una estructura relacional, utilizan InnoDB):
table: account_groups (Broader account groupings)
Fields:
-id_key - primary key, auto number
-group - unique index
-parent - index, foreign key=account_groups.group (this allows you to create group trees, so you can specify that a county group belongs to a state, and a municipality belongs to a county group, etc.)
-group_hierarchy - integer (0 is highest permission group, each subsequent one step lower)
table: account_levels (Account levels within a group)
Fields:
-id_key - primary key, auto number
-account_level - unique index
-group - index, foreign key=account_groups.group
-account_heirarchy - integer (same as other table but denotes heirarchy within the group
table: user_accounts (Individual user accounts)
Fields:
-id_key - primary key, auto number
-account_id - unique index, user account name
-account_level - index, foreign key=account_levels.account_level
table: user_groups (denotes which tree(s) the user has access to)
Fields:
-id_key - primary key, auto number
-account_id - index, foreign key=user_accounts.account_id
-group - index, foreign key=account_groups.group
y luego por los permisos:
table: permissions (directory of permissions that could be applied)
Fields:
-id_key - primary key, auto number
-permission - unique index, permission identifier
-other stuff you need associated with the individual permissions, based on how you want them to hook into your program
table: permissions_group_permissions (permissions applied at group level)
Fields:
-id_key - primary key, auto number
-group - index, foreign key=account_groups.group
-permission - index, foreign key= permissions.permission
table: permissions_account_permissions (permissions applied at account level)
Fields:
-id_key - primary key, auto number
-account_type - index, foreign key=account_levels.account_level
-permission - index, foreign key=permissions.permission
table: permissions_individual_permissions (permissions applied to individual accounts, if neccessary)
Fields:
-id_key - primary key, auto number
-account_id - index, foreign key=user_accounts.account_id
-permission - index, foreign key=permissions.permission
-allow_or_deny - boolean (TRUE means permission is granted, FALSE means permission if revoked. This allows you to fine tune individual accounts, either granting custom elevated permissions, or revoking individual permissions for troublesome accounts without demoting them from the group. This can be useful in some special circumstances)
-expiration - timestamp (allows you to set expiration dates for permissions, like if you want to temporarily suspend a specific action. Programmatically set default value of 00/00/00 00:00:00 as indefinite. You can do this at the account and group levels too by adding this field to those tables.)
luego, puede usar PHP para iterar a través de los permisos de la cuenta individual por fi Primero obtener el grupo asociado con el nivel de cuenta, hacer una matriz de cada grupo subsiguiente en el orden jerárquico y luego iterar a través del orden jerárquico para el grupo actual (agregar como matriz multidimensional a matriz de grupo) desde el nivel de cuenta actual dentro del grupo hasta el último nivel de cuenta existente dentro del grupo. A continuación, tomaría todo el nivel de la cuenta para cada grupo subsiguiente y finalmente obtendría todos los permisos asociados para cada nivel de cuenta que se haya agregado a la matriz. Si implementa los permisos de usuario individuales, deberá agregar su matriz de permisos con los permisos aplicados individualmente y, por último, eliminar todos los permisos de su matriz que tengan su campo allow_or_deny establecido en FALSE. Si el usuario necesita tener acceso a múltiples árboles, agregue un registro a la tabla account_groups que coincida con su ID de cuenta, que indique cuál es el nivel más alto del árbol al que tienen acceso, y luego itere a través de todos los grupos subsiguientes en el árbol. Para otorgar todos los permisos aplicables a la cuenta, tome todas las asociaciones de grupo para el account_id de user_groups, y luego ejecute el proceso descrito anteriormente para cada árbol. Si solo tienen acceso a un árbol, ni siquiera necesita usar la tabla user_groups.
an example of how the structure fits your model:
group: USA, hierarchy = 0
group: California, parent-> USA, hierarchy = 1
group: Los Angeles, parent->California, hierarchy = 2
group: Texas, parent->USA, hierarchy = 1
group: Dallas, parent->Texas, hierarchy = 2
Los miembros del grupo EE. UU. Pueden acceder a todo. Los miembros de California puede acceder a todos los grupos subsiguientes en la jerarquía de California, pero no grupos de Texas, a pesar de que tienen el mismo valor jerárquico (porque son diferentes ramas de los padres)
account levels:
admin, hierarchy=0
manager, hierarchy=1
analyst, hierarchy=2
staff member, hierarchy=3
Cada nivel cuenta tiene toda la permisos para cada nivel de cuenta posterior.
user accounts:
Bob, manager (likes to spam junk email to everyone)
todavía puede revocar el permiso para enviar por correo electrónico Bob añadiendo el permiso de correo electrónico a permissions_individual_permissions y estableciendo el valor allow_or_deny a FALSO. Esto le permite detener a Bob de enviar spam sin degradarlo de la administración.
Además, esto le permitirá establecer diferentes niveles de permisos para diferentes árboles, por lo que un solo usuario podría tener acceso de estado en un árbol, pero solo acceso municipal en otro árbol. – mopsyd