Come devo tracciare il flusso di lavoro di approvazione quando gli utenti a tutti i livelli di sicurezza possono creare una richiesta?

0

Sto scrivendo una nuova applicazione che consente agli utenti di inserire le richieste.

Una volta che una richiesta è stata inserita, deve seguire un flusso di lavoro di approvazione per essere infine approvato da un utente il più alto livello di sicurezza.

Quindi, diciamo che un utente al livello di sicurezza 1 inserisce una richiesta. Questa richiesta deve essere approvata dal suo superiore - un utente al livello di sicurezza 2. Una volta che l'utente del livello di sicurezza 2 lo approva, deve essere approvato da un utente al livello di sicurezza 3. Una volta che l'utente del livello di sicurezza 3 lo approva, viene considerato completamente approvato.

Tuttavia, gli utenti di uno qualsiasi dei tre livelli di sicurezza possono inserire richieste. Quindi, se un utente di livello di sicurezza 3 inserisce una richiesta, viene automaticamente considerato "completamente approvato". E, se un utente di livello di sicurezza 2 inserisce una richiesta, deve essere approvato solo da un utente di livello di sicurezza 3.

Attualmente sto memorizzando ogni stato di approvazione in una tabella dei registri database, in questo modo:

STATUS_ID (PK) REQUEST_ID    STATUS           STATUS_DATE
-------------- ------------- ---------------- -----------------------
1              1             USER_SUBMIT      2012-09-01 00:00:00.000
2              1             APPROVED_LEVEL2  2012-09-01 01:00:00.000
3              1             APPROVED_LEVEL3  2012-09-01 02:00:00.000
4              2             USER_SUBMIT      2012-09-01 02:30:00.000
5              2             APPROVED_LEVEL2  2012-09-01 02:45:00.000

La mia domanda è, che è un design migliore:

  1. Registra tutti e tre gli stati per ogni richiesta ... o ...
  2. Registra solo gli stati necessari in base al Livello di sicurezza dell'utente che ha inviato la richiesta

Nel caso 2, i dati potrebbero essere simili a due richieste: una inviata dall'utente Security Level 2 e un'altra inviata dall'utente Security Level 3:

STATUS_ID (PK) REQUEST_ID    STATUS           STATUS_DATE
-------------- ------------- ---------------- -----------------------
1              3             APPROVED_LEVEL2  2012-09-01 01:00:00.000
2              3             APPROVED_LEVEL3  2012-09-01 02:00:00.000
3              4             APPROVED_LEVEL3  2012-09-01 02:00:00.000
    
posta Eric Belair 07.09.2012 - 16:01
fonte

2 risposte

2

Considererei i tag "auto approvati" per i casi in cui un utente di Livello 2 o 3 crea una richiesta.

La mia presunzione è che stai monitorando:

  • chi crea
  • che approva al livello 2
  • che approva al livello 3

Quindi il tuo stato potrebbe quindi analizzare quanto segue:

  • User_submit
  • Approved_Level2 o Auto_Approved_L2
  • Approved_Level3 o Auto_Approved_L3

Ciò ti consentirebbe di tenere traccia dei casi in cui le cose sono auto-approvate, ma mantengono comunque lo stesso / simile percorso di codice per tutti i ticket di lavoro. In modo che dovrebbe soddisfare le vostre esigenze e memorizzare informazioni significative. Supponendo che ti interessi dei casi tra un'autorizzazione effettiva e un'autorizzazione automatica.

Quindi sto votando per una versione modificata del caso 1.

    
risposta data 07.09.2012 - 16:45
fonte
1

Opzione 2, naturalmente.

Perché desideri memorizzare ulteriori dati inutili?

Semplicemente confonderà le cose e aggiunge NO value.

    
risposta data 07.09.2012 - 16:08
fonte

Leggi altre domande sui tag