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