Get Started. It's Free
or sign up with your email address
Incident by Mind Map: Incident

1. OrderId

1.1. opzionale, eventuale ordine collegato al ticket

1.2. per il futuro: meglio meccanismo generico di RefTable e RefId (?)

2. OrderRowId

2.1. opzionale, eventuale riga (quindi prodotto) collegata al ticket

3. Date

3.1. giorno + ora di apertura incident

3.1.1. Utc, da mostrare localizzato

4. Status

4.1. stato dell'incident

4.2. enum da definire

5. ShopId

5.1. opzionale, eventuale Shop coinvolto

6. AssignedToId

6.1. opzionale, ID del BusinessUser che ha preso in carico l'incident

7. VisibilityLevel

7.1. enum che indica la visibilità minima necessaria (Consumer, Business, Admin).

7.2. assegnato in automatico in base a chi ha aperto l'incident

8. come capisco da chi deve essere preso in carico l'incident?

8.1. se aperto dal consumer user deve essere un business user

8.2. se aperto da un business user deve essere un altro business user diverso da se stesso

9. Attachments

9.1. tabella generica per gestire allegati collegati ad un'entità

9.2. ID

9.3. EntityTypeId

9.3.1. EntityTypeEnum, elemento esistente

9.4. EntityId

9.4.1. ID dell'entità associata all'allegato

9.5. UserType

9.5.1. UserTypeEnum, elemento esistente

9.6. UserId

9.6.1. ID dell'utente che ha caricato l'allegato

9.7. Description

9.7.1. opzionale, eventuale descrizione/note relative all'allegato

9.8. AttachPath

9.8.1. path relativo dove è stato salvato l'allegato

9.8.1.1. prevedere alberatura sotto azure

9.8.1.1.1. folder senza possibilità di navigazione

9.8.1.1.2. nome del file = guid per evitare sovrapposizioni

9.8.1.1.3. parte sotto settings + EntityTypeId + EntityId

9.9. OriginalFileName

9.9.1. nome del file originale all'atto del caricamento

9.10. Extension

9.10.1. estensione del file

9.11. ContentType

9.12. TS

9.12.1. timestamp

10. Incident Linked

10.1. ID

10.2. MainIncidentId

10.3. SlaveIncidentId

10.4. permette di aprire incident secondary in un incident primario

10.4.1. utilizzabile ad esempio nel caso il business user a fronte di un incident di consumer user voglia aprire un incident all'operatore tailoor

10.4.2. utilizzabile ad esempio nel caso il business user a fronte di un incident di ramake di un prodotto, voglia tenere traccia della lavorazione in maniera separata

10.4.3. solo un business user può aprire un incident secondario

10.4.3.1. il consumer user non ha visibilità di nessun incident secondario

10.4.3.2. un ticket aperto da un business user con permesso TailoorAdmin può essere visto solo da altri business user con questo permesso

11. ID

12. Code

12.1. alfanumerico, da mostrare e usare per le comunicazioni

13. ConsumerUserId

13.1. opzionale, il Customer potrebbe aprire un ticket a Tailoor relativo alla piattaforma

14. CustomerId

14.1. obbligatorio

15. OpenedBy

15.1. OpenedById

15.1.1. obbligatorio. ID di chi ha aperto l'incident, può essere un ID che fa riferimento alla tabella ConsumerUsers o alla BusinessUsers

15.2. OpenedByType

15.2.1. UserTypeEnum (già esistente)

16. IncidentTypeId

16.1. riferimento ad entità AttributeValues, Attribute = IncidentType

17. Description

17.1. descrizione dell'incident, testo libero

18. visibilità incident

18.1. consumer che ha creato

18.2. business user del Customer con permessi ManageIncident

18.3. business user Tailoor con permesso TailoorAdmin

18.3.1. operatore Tailoor deve essere associato al customer per poter gestire gli incident

18.3.2. TailoorAdmin è un permesso Internal non associabile dal Customer

18.3.3. modifica API pagina BusinessUsers: filtrare gli utenti che hanno questo permesso, non possono essere rimossi e gestiti dal Customer

19. Notes

19.1. elemento generico già esistente

19.1.1. necessario introdurre nuovo campo Group (stringa, opzionale) da utilizzare per effettuare dei raggruppamenti logici

19.2. Group = internal note

19.2.1. visibili solo ai business user che possono accedere all'incident

19.2.1.1. deve essere escluso OpenedById, perché potrebbe essere un Incident aperto dal Business User di un Customer verso un Business User Tailoor

19.3. Group = chat

19.3.1. visibili a tutti quelli che possono accedere all'incident

20. Costs

20.1. costi associati all'incident

20.2. possono essere inseriti e visti solo dai Business Users

20.3. ID

20.4. PayedBy

20.4.1. Customer

20.4.2. Consumer User

20.4.3. Tailoor

20.4.3.1. voce visibile sono se business user con permesso TailoorAdmin

20.4.4. campo obbligatorio

20.5. PaymentTypeId

20.5.1. campo obbligatorio, forma di pagamento

20.5.2. riferimento ad entità AttributeValues, Attribute = IncidentPaymentType

20.6. CostTypeId

20.6.1. obbligatorio, tipologia di costo

20.6.2. riferimento ad entità AttributeValues, Attribute = IncidentCostType

20.7. Amount

20.7.1. importo pagato, obbligatorio e può essere 0

20.8. Attachments

20.8.1. possibilità di caricare dei file

20.8.2. vedi sezione Attachments

20.9. Date

20.9.1. obbligatorio, data pagamento

21. Timeline

21.1. elemento esistente

21.2. serve a registrare tutto quello che succede sull'incident (eventi)

21.3. la logica di registrazione di un evento dipende dalla circostanza, da vedere caso per caso

22. Attributes

22.1. tabella esistente, necessario aggiungere alcuni campi ai valori degli attributi

22.2. AttributeValues

22.2.1. VisibilityLevel

22.2.1.1. opzionale, enum che indica la visibilità minima necessaria (Consumer, Business, Admin).

22.2.2. SortOrder

22.2.2.1. opzionale, default 0. Indica l'eventuale ordinamento da dare agli elementi all'interno di un LookupType. Ordinamento crescente

22.2.2.2. Dubbio Massimiliano: forse serve più complesso => al momento non lo mettiamo, niente complessità troppo elevate

22.2.3. IsActive

22.2.3.1. default true