Progettazione di un modello di stato utente complesso

2

Sto scrivendo un programma con la seguente modalità concettuale.

A User can apply to become an employee, which places their account in a Pending state. They can then be Approved or Rejected. The only person who can put an account in the Pending state is the user themselves.

An Administrator can move users to and between the Approved and Rejected states (they are notified whenever a user enters the Pending state). They can also promote the account to become an Supervisor (I), Supervisor (II), or Administrator.

All Supervisors have the privileges of an Approved user in relation to their own account (e.g. schedule a vacation). They also have additional privileges (e.g. view any employee's phone number). No class of Supervisors necessarily has all the privileges of any other Supervisor class. A user can be more than one type of Supervisor at once.

Administrators have the privileges of Approved users in relation to their own account, as well as he privileges of all types of Supervisors.

Tuttavia, ho difficoltà a trovare un buon modo per rappresentarlo. In particolare, la linea in grassetto significa che non ha senso utilizzare solo un singolo user_status enum.

Poiché desidero anche la promozione all'accesso da supervisore / amministratore dallo stato di dipendente regolare per richiedere la nuova autenticazione per l'amministratore, sembra opportuno distinguere (Nessuno) / In attesa / Approvato / Rifiutato (che sono intrinsecamente mutuamente esclusivi) da lo stato Supervisore / Amministratore.

La cosa migliore che ho inventato finora è essenzialmente qualcosa del seguente:

public class Employee {
    // user id, name, etc.
    ArrayList<EmployeeRole> roles;
    EmployeeStatus status;
}

public enum EmployeeRole {
    Employee, SupervisorI, SupervisorII, ..., Administrator
}

public enum EmployeeStatus {
    None, Pending, Approved, Rejected
}

Tuttavia, questo non rappresenta bene il modello dei privilegi (in modo tale che non sono sicuro di quale possa essere l'aspetto di un progetto compatibile). Qualche suggerimento per una soluzione migliore?

    
posta alks 18.10.2017 - 01:45
fonte

1 risposta

1

Perks

Ecco la mia idea: hai un elenco di permessi / privilegi (in breve chiamiamoli vantaggi). Un ruolo contiene uno o più vantaggi, ma la proprietà non , ovvero un dato vantaggio in un ruolo non significa necessariamente che è l'unico ruolo con detto vantaggio.

Ruoli

Utente, Dipendente, Supervisore (I), Supervisore (II), Supervisore (III), Amministratore sono tutti solo ruoli per il tuo programma. Fai un respiro profondo e ripeti. Utente, Dipendente, Supervisore (I), Supervisore (II), Supervisore (III), Amministratore sono tutti solo ruoli per il tuo programma.

Ora, per evitare complicazioni in futuro, è necessario associare uno stato a ciascun ruolo assegnato a un utente. Lo stato può essere In sospeso, Approvato, Rifiutato. Questo implica due cose:

  1. Un utente può avere diverse richieste in sospeso potenzialmente (se si decide che un solo ruolo può essere sospeso in un momento, che può essere applicato eseguendo un semplice controllo).
  2. L'aggiunta di una nuova richiesta è semplice come aggiungere un ruolo con stato In sospeso all'utente in questione. Non dimenticare di filtrare i ruoli che non hanno lo stato "Accettato" prima di prendere in considerazione le autorizzazioni di un utente!

Flessibilità

Questo ha il vantaggio aggiunto che è completamente flessibile. Si salvano le informazioni nel livello dati come tali e si può ottimizzare il comportamento a livello aziendale. Se in seguito, il comportamento del programma cambia, è necessario modificare solo la logica aziendale per l'aggiornamento del livello dati.

Possiamo anche utilizzare questo sistema per migliorare se stesso. Ad esempio, possiamo creare un perk che consente a un utente di aggiungere / rimuovere ruoli a un altro utente. Quindi, piuttosto che controllare se l'utente corrente è un amministratore, si controlla solo l'esistenza di questo vantaggio. In questo caso, è possibile presentare la GUI corretta per consentire a detto utente di aggiungere / rimuovere vantaggi a un altro utente.

Possiamo farcela. Possiamo creare un Perk che consente a un utente di essere in grado di approvare immediatamente un ruolo aggiunto a un utente. Quando un utente tenta di aggiungere un nuovo ruolo a un utente, è possibile controllarlo per questo perk e, se esiste, anziché impostare lo stato PENDING, impostarlo direttamente su APPROVED.

Si noti che sarebbe un errore verificare i ruoli di un determinato utente. I ruoli esistono solo per i vantaggi del gruppo. L'esistenza dei vantaggi offerti dai ruoli di un utente è ciò che ti dice ciò che un utente può e non può fare. Questo è importante in quanto significa che non è necessario sapere se un utente ha o meno un ruolo di amministratore. Il tuo programma può funzionare interamente con l'uso di ruoli astratti, con l'eccezione minore del livello dati che carica i benefici per un determinato utente.

Perché gli amministratori di sistema ti adoreranno

In seguito e solo una volta che il precedente funziona senza problemi, se pensi che l'elenco dei vantaggi sia numeroso, dovresti considerare di consentire a un ruolo di contenere anche altri ruoli oltre ai vantaggi. Ad esempio, l'amministratore ha tutti gli altri ruoli, quindi se i nuovi vantaggi vengono aggiunti ad altri ruoli, l'amministratore li avrà anche per impostazione predefinita, ad esempio). Tuttavia, questo non è strettamente necessario. Inoltre, se si decide di intraprendere questa strada, sarà necessario verificare rapidamente che non si stia creando una dipendenza ciclica (l'amministratore non può aggiungere il ruolo Supervisor (III) se Supervisore (III) ha già un amministratore di ruolo, ad esempio).

Spero che ti aiuti!

    
risposta data 18.10.2017 - 09:38
fonte

Leggi altre domande sui tag