Suggerirei di creare una serie di gruppi di utenti nel proprio database, ognuno dei quali ha uno o più livelli di account utente al suo interno, quindi assegnare un numero intero come valore gerarchico al gruppo, quindi fare lo stesso per il singolo account livelli all'interno del gruppo, qualcosa di simile (si tratta di una struttura relazionale, utilizzare 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
E poi per i permessi:
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.)
è possibile quindi usare php per scorrere le autorizzazioni per il singolo account di fi per ottenere il gruppo associato al livello dell'account, creando una matrice di ogni gruppo successivo nell'ordine gerarchico, quindi eseguendo l'iterazione dell'ordine gerarchico per il gruppo corrente (aggiungi come array multidimensionale all'array di gruppi) dal livello di account corrente all'interno del gruppo all'ultimo livello di account esistente all'interno del gruppo. Successivamente si dovrebbe prendere tutto il livello di account per ogni gruppo successivo e infine recuperare tutte le autorizzazioni associate per ogni livello di account che è stato aggiunto all'array. Se si implementano le autorizzazioni individuali dell'utente, sarà necessario aggiungere l'array di autorizzazioni con le autorizzazioni applicate individualmente e infine rimuovere le autorizzazioni che dall'array hanno il proprio campo allow_or_deny impostato su FALSE. Se l'utente deve avere accesso a più alberi, si aggiunge un record alla tabella account_groups che corrisponde al proprio ID account, che indica quale sia il livello più alto dell'albero a cui hanno accesso e quindi itera su tutti i gruppi successivi nella struttura. Per concedere tutte le autorizzazioni applicabili all'account, prendi tutte le associazioni di gruppo per account_id da user_groups, quindi esegui il processo descritto in precedenza per ogni albero. Se hanno solo accesso a un albero, non è nemmeno necessario utilizzare la tabella 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
I membri del gruppo USA possono accedere a tutto. I membri della California possono accedere a tutti i gruppi successivi nella gerarchia per la California, ma non i gruppi per il Texas, anche se hanno lo stesso valore gerarchico (perché sono diversi rami parentali)
account levels:
admin, hierarchy=0
manager, hierarchy=1
analyst, hierarchy=2
staff member, hierarchy=3
Ogni livello di account ha tutte le autorizzazioni per ogni successivo livello di account.
user accounts:
Bob, manager (likes to spam junk email to everyone)
è ancora possibile revocare il permesso email per Bob aggiungendo il permesso e-mail a permissions_individual_permissions e impostando il valore allow_or_deny FALSE. Ciò consente di impedire a Bob di effettuare lo spamming senza sottrarlo alla gestione.
Inoltre, questo consente di impostare diversi livelli di autorizzazione per diversi alberi, in modo che un singolo utente possa avere accesso allo stato in un albero, ma solo accesso municipale in un altro albero. – mopsyd