BR-REQ — Regole di business del dominio Service Desk (RequestCenter)

Regole di business estratte dal flusso pilota FLOW-REQ-001 (creazione richiesta/ticket) e dai sorgenti del modulo RequestCenter. Sistema Infocad (Descor): backend Oracle (nessun ORM, stored procedure via DAL), frontend ASP.NET Web Forms (VB.NET) + servizi WCF. Prosa in italiano; identificatori (classi/metodi/proc/colonne) non tradotti.

Dominio: Service Desk / RequestCenter (creazione richieste, protocollo, workflow DEM)
Flusso di riferimento: docs/07-business-flows/FLOW-REQ-001.md
Confidenza complessiva: VERIFIED (catena UI→BL→DAL→proc) · SUPPORTED (mappa proc→tabelle dal catalogo dipendenze)
Schema DB pilota: REQUESTCENTER_TEST38, DEM_TEST38, INFOCAD_TEST38 (osservato solo ambiente TEST38)

Legenda enforcement

UI = validato solo nel code-behind/controlli ASP.NET (rischio: bypassabile via chiamata BL/WCF diretta)
BL = logica nel Business Layer VB.NET (RequestCenter.Ticket.Request, DEM.*)
DB = vincolo/sequence/trigger/procedura Oracle
mixed = combinazione dei precedenti

Registro delle regole

id	regola (sintesi)	tipo	enforcement	conf.
BR-REQ-001	Accesso al modulo solo se autenticato e `RequestCenterEnabled` o super-admin	permission	mixed (UI+WCF)	VERIFIED
BR-REQ-002	L'operatore vede solo i call type del proprio ruolo con attività di creazione	permission	mixed (UI+BL)	VERIFIED
BR-REQ-003	Tre tipi di chiamata (Ticket/Anomaly/Info) identificati da GUID hard-coded	config-flag	BL	VERIFIED
BR-REQ-004	Momento di creazione del protocollo `Before`/`After` (parametrico)	config-flag	BL	VERIFIED
BR-REQ-005	Suffisso protocollo diverso per tipo call (parametrico, personalizzabile)	calculation	BL	VERIFIED
BR-REQ-006	`HeavyLoadMode` alterna selettore utente vs contatto obbligatorio	config-flag	UI	VERIFIED
BR-REQ-007	Validazione campi obbligatori del form prima di aprire la transazione	validation	UI	VERIFIED
BR-REQ-008	Call type Ticket richiede info spaziale + alert/scadenza	validation	UI	VERIFIED
BR-REQ-009	Call type Anomaly: alert non richiesto, dettaglio spaziale sì	validation	UI	VERIFIED
BR-REQ-010	Call type Info: nessun dettaglio spaziale né alert	validation	UI	VERIFIED
BR-REQ-011	Blocco creazione figlio se lo stato di padre/fratello è cambiato	state-transition	mixed (UI+BL)	VERIFIED
BR-REQ-012	Creazione atomica: tutto in transazione, rollback su eccezione	state-transition	BL	VERIFIED
BR-REQ-013	Insert richiesta restituisce id via parametro OUT `NEWREQUESTINDEX`	calculation	mixed (BL+DB)	VERIFIED
BR-REQ-014	Radice richiesta scritta su `REQUESTREGISTRY`/`REQUESTREGISTRYDATA`	validation	DB	SUPPORTED
BR-REQ-015	Variante senza protocollo (portale self-service)	config-flag	mixed (BL+DB)	VERIFIED
BR-REQ-016	Workflow a singola attività ⇒ create-close automatico	state-transition	BL	VERIFIED
BR-REQ-017	Creazione elemento workflow DEM in stato iniziale	state-transition	mixed (BL+DB)	VERIFIED
BR-REQ-018	Aggancio richiesta↔elemento workflow (`REQUESTWORKFLOWINTERFACE`)	state-transition	mixed (BL+DB)	VERIFIED
BR-REQ-019	Calcolo scadenza per `ExpireDateMode` (GLOBALALERT/USERINPUT/ALL)	date-logic	BL	VERIFIED
BR-REQ-020	Messaggio iniziale sull'elemento con livello `NoLevel`	state-transition	BL	VERIFIED
BR-REQ-021	Notifica mail solo se `MailingType <> "none"`	config-flag	BL	VERIFIED
BR-REQ-022	Cancellazione protocollo temporaneo sempre in `Finally`	state-transition	BL	VERIFIED
BR-REQ-023	Collegamento a richiesta padre (sub-lavoro) con messaggio e descrizione	state-transition	BL	VERIFIED
BR-REQ-024	Calcolo sub-protocollo figlio con separatore e livello	calculation	BL	VERIFIED
BR-REQ-025	Ritorno protocollo a ScheduleCenter se generato da ODL	customer-specific	BL	SUPPORTED
BR-REQ-026	Redirect post-creazione dipende da `CreationMoment` + `NavigationSource`	state-transition	UI	VERIFIED
BR-REQ-027	Azioni extra-flusso via WCF: autenticazione + tipo attività Create/CreateClose	permission	mixed (WCF+BL)	VERIFIED
BR-REQ-028	Valori di default hard-coded alla creazione (Deferability=0, Type=0)	config-flag	BL	VERIFIED
BR-REQ-029	Selezione DAL read-only vs read-write via `DALUseReaders`	config-flag	BL	VERIFIED

Dettaglio regole

BR-REQ-001 — Gate di accesso al modulo RequestCenter

Statement: L'accesso alle pagine RequestCenter è consentito solo se l'utente è autenticato e possiede il flag RequestCenterEnabled, oppure è super-admin (IsUserSuperAdmin); altrimenti redirect a FormsAuthentication.DefaultUrl. Sul canale WCF il gate equivalente è ValidateLoginKey.

Tipo: permission · Enforcement: mixed (UI + WCF) · Confidence: VERIFIED · customer_specific: false
Evidenza: CommonWeb/RequestCenter/Classes/Base/RequestCenterPage.vb:74,77,82 (Page_PreInit → If Not ... RequestCenterEnabled AndAlso Not ... IsUserSuperAdmin Then Response.Redirect(...DefaultUrl)); WCF ExtraFlowActionsProxy.svc.vb:56,64 (If ValidateLoginKey(...)).
Nota rischio: il gate UI protegge solo le pagine; l'entry point BL Request.Create è condiviso da WCF/portale/helper (vedi reverse-trace del flusso), quindi l'autorizzazione deve essere garantita a monte da ciascun canale.

BR-REQ-002 — Call type filtrati per ruolo con attività di creazione

Statement: L'operatore può creare solo richieste dei call type per cui il proprio ruolo (IdRole) dispone di un'attività di creazione nel workflow associato.

Tipo: permission · Enforcement: mixed (UI + BL) · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:37 (RequestHelper.CallTypesByRoleWithCreatingActivity(_currentuser.Role.IdRole)), :57 (LoadCreatingPermissions); CreateUserControlBase.vb:1990-1998.

BR-REQ-003 — Tre tipi di chiamata con GUID hard-coded

Statement: Il dominio prevede tre macro-tipi di chiamata — Ticket, Info, Anomaly — identificati da GUID costanti nel codice. Un call type non riconosciuto viene trattato come Ticket (fallback).

Tipo: config-flag (hard-coded id) · Enforcement: BL · Confidence: VERIFIED · customer_specific: false
Evidenza: RequestCenter/Constants/Constants.vb:45-47: Ticket = "A6D678E1-85E9-49e6-9173-D4C636B8E065", Info = "3BB99853-0F6B-472b-9F21-F41ABD572B65", Anomaly = "B4BD6334-80F9-4c8d-AF49-E1D1EE6689AA". Uso in makeTicket.ascx.vb:98-106,119,141; fallback Case Else → GetTicketSuffix (:104-105) e SetCallType (Request.vb:2506-2508).
Flag: hard-coded ids (GUID magici, non configurabili).

BR-REQ-004 — Momento di creazione del protocollo (Before/After)

Statement: Il protocollo può essere generato prima (Before) o dopo (After) la validazione/insert, in base al parametro GetCreationMoment. Con After il protocollo viene calcolato solo dopo il superamento della validazione, appena prima dell'insert; determina anche il comportamento di redirect post-salvataggio (vedi BR-REQ-026).

Tipo: config-flag · Enforcement: BL · Confidence: VERIFIED · customer_specific: true (valore fornito dal provider parametrico DynamicParametric)
Evidenza: makeTicket.ascx.vb:94-109 (If Parametric.RequestCenter.Protocol.GetCreationMoment = ...After Then MakeProtocol(...)); Customizations/Parametric/RequestCenter/Protocol.vb:29-35; enum IProtocol.vb (CreationMoments {Before, After}).
Flag: hidden feature flag parametrico risolto a runtime via Evaluating.Instance.EvalAsync.

BR-REQ-005 — Suffisso protocollo per tipo call

Statement: Il suffisso applicato al codice protocollo dipende dal tipo di chiamata: GetTicketSuffix / GetAnomalySuffix / GetInfoSuffix. Le funzioni sono risolte dinamicamente dal motore parametrico (personalizzabili per cliente).

Tipo: calculation · Enforcement: BL · Confidence: VERIFIED · customer_specific: true
Evidenza: makeTicket.ascx.vb:97-106 (Select Case su selectedCallType.GUID); Customizations/Parametric/RequestCenter/Protocol.vb:8-27 (Evaluating.Instance.EvalAsync(Of String)("GetTicketSuffix") ecc.).
Flag: customer-specific variant (implementazione parametrica per installazione).

BR-REQ-006 — HeavyLoadMode: utente vs contatto obbligatorio

Statement: Se HeavyLoadMode = False, è obbligatorio il selettore utente (UserSelector1, visibile e IsRequired = True) e il selettore contatto è nascosto; se HeavyLoadMode = True vale l'inverso (contatto cntSelHL obbligatorio).

Tipo: config-flag · Enforcement: UI · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:19-29; RequestCenter/Configuration/Settings.vb:197-201 (HeavyLoadMode).
Flag: UI-only (obbligatorietà imposta solo nei controlli lato pagina).

BR-REQ-007 — Validazione campi obbligatori prima della transazione

Statement: Prima di aprire la transazione vengono eseguiti DoValidation() e ValidateUpload(...); se errLog.ErrorStrings.Count > 0 la creazione si arresta senza aprire alcuna transazione né scrivere dati.

Tipo: validation · Enforcement: UI · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:84-87 (errLog.ErrorStrings = Me.DoValidation() / ValidateUpload(...) / If errLog.ErrorStrings.Count = 0 Then), ramo Else → errLog.DataBind() (:257-258).
Flag: UI-only (i controlli di obbligatorietà non sono ripetuti a livello BL/DB; una chiamata diretta a Request.Create li aggira).

BR-REQ-008 — Ticket: info spaziale e alert/scadenza obbligatori

Statement: Per il call type Ticket la sezione spaziale (SpatialSelection1) e il controllo alert/scadenza (AlertControl1) sono resi visibili e obbligatori (IsRequired = True); alla creazione vengono impostati SetSpatialInfo, SetManagement, SetContract, SetCompany, SetExpiry.

Tipo: validation · Enforcement: UI · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:325-336 (ManageTicketMode: AlertControl1.Visible = True, AlertControl1.IsRequired = True), ManageDetailsView :293,299,307; ramo Ticket in btnPost_Click :119-137.
Flag: UI-only.

BR-REQ-009 — Anomaly: alert non richiesto

Statement: Per il call type Anomaly il controllo alert è nascosto e non obbligatorio, mentre il dettaglio spaziale resta attivo; alla creazione si impostano oggetto di manutenzione, componenti, management/contract/company (ma non la scadenza da alert).

Tipo: validation · Enforcement: UI · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:311-323 (ManageAnomalyMode: AlertControl1.Visible = False / AlertControl1.IsRequired = False, ManageDetailsView(True)); ramo Anomaly :141-157.
Flag: UI-only.

BR-REQ-010 — Info: nessun dettaglio spaziale

Statement: Per il call type Info la sezione dettaglio/spaziale è disabilitata (ManageDetailsView(False)): l'insert richiesta non gestisce spaziale/oggetti.

Tipo: validation / state-transition · Enforcement: UI · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:338-346 (ManageInfoMode → ManageDetailsView(False)).
Flag: UI-only.

BR-REQ-011 — Blocco su cambio stato di padre/fratello (guardia di concorrenza)

Statement: Prima del salvataggio si verifica se lo stato del ticket padre e/o fratello è cambiato dall'ultima azione (confronto tra ParentLastActivityDate/SiblingLastActivityDate e l'ultima DateChangeState della history). Se è cambiato, la creazione non procede e viene aperta una finestra di alert.

Tipo: state-transition (concurrency guard) · Enforcement: mixed (UI + BL) · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:83 (If Not CheckParentStateChange() AndAlso Not CheckSiblingStateChange() Then ...), ramo Else → OpenAlertWindow() :260-263; CreateUserControlBase.vb:1895-1909 (refresh history + confronto date).

BR-REQ-012 — Creazione atomica in transazione

Statement: Tutte le scritture (insert richiesta, descrizione, custom fields, allegati, elemento workflow, aggancio WF) avvengono tra Begin() e Commit(). Un'eccezione produce Rollback(), rollback degli allegati (uplFilesPanel.GoRollBack()), refresh cache e log errore: nessun ticket viene persistito.

Tipo: state-transition (integrità) · Enforcement: BL · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:88,111-112 (OpenConnection/Begin), :216 (Commit), :238-255 (Catch → Rollback, Finally → CloseConnection).

BR-REQ-013 — Insert richiesta con id da parametro OUT

Statement: L'insert della richiesta con protocollo restituisce l'id generato via parametro OUT NEWREQUESTINDEX (identity applicativa, non auto-increment): Request.Create → dal.addRequest → GESTREQUEST_T2.ADDREQUEST.

Tipo: calculation · Enforcement: mixed (BL + DB) · Confidence: VERIFIED · customer_specific: false
Evidenza: Request.vb:2222-2225 (Create(iduser, idtenant, protocol, protocolcode, subcode, protocollevelparent, requestdate)); RequestDAL.vb:5054,5078 (GESTREQUEST_T2.ADDREQUEST, OUT NEWREQUESTINDEX); chiamata makeTicket.ascx.vb:114.

BR-REQ-014 — Radice richiesta su REQUESTREGISTRY / REQUESTREGISTRYDATA

Statement: La riga radice della richiesta è scritta nelle tabelle REQUESTREGISTRY e REQUESTREGISTRYDATA (schema REQUESTCENTER_TEST38), con sequence dedicata, dai package GESTREQUEST_T2/GESTREQUEST.

Tipo: validation (integrità dati) · Enforcement: DB · Confidence: SUPPORTED · customer_specific: false
Evidenza (catalogo dipendenze read-only stored-procedure-dependencies.csv): REQUESTCENTER_TEST38,GESTREQUEST_T2,PACKAGE BODY,...,REQUESTREGISTRY,TABLE,RW e ...,REQUESTREGISTRYDATA,TABLE,RW; REQUESTCENTER_TEST38,GESTREQUEST,PACKAGE BODY,...,REQUESTREGISTRY,TABLE,WRITE.
Nota: granularità a livello package body → non è isolabile la singola proc ADDREQUEST; la mappa tabella↔proc puntuale resta open question (vedi FLOW-REQ-001).
Flag: DB-only (integrità strutturale garantita dal package/sequence, non ispezionati vincoli/trigger nel dettaglio).

BR-REQ-015 — Variante senza protocollo (portale self-service)

Statement: Esiste un overload di creazione senza protocollo — Request.Create(iduser, idtenant, requestdate) → GESTREQUEST.ADDREQUESTWITHOUTPROTOCOL — usato dai path portale (makeWebTicket_*, NavigationSource=AutoTicket).

Tipo: config-flag / branch · Enforcement: mixed (BL + DB) · Confidence: VERIFIED · customer_specific: false
Evidenza: Request.vb:2227-2230; RequestDAL.vb:5105 (ADDREQUESTWITHOUTPROTOCOL); reverse-trace FLOW-REQ-001 (chiamanti portale/WCF).

BR-REQ-016 — Workflow a singola attività ⇒ create-close

Statement: Se il workflow associato al call type ha una sola attività (actionWF.WorkflowActivities.Count = 1), la richiesta viene subito chiusa alla creazione (SetAlert(0) + _objRequest.Close()), realizzando il pattern "create-close". A livello DEM esiste il tipo attività dedicato CreateClose.

Tipo: state-transition · Enforcement: BL · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:138-140 (ElseIf actionWF.WorkflowActivities.Count = 1 Then _objRequest.SetAlert(0) : _objRequest.Close()); Request.vb:2758-2778 (Close); GUID DEM/Constants.vb:9,11 (Create, CreateClose).
Flag: magic number (Count = 1); hard-coded id (CreateClose GUID CE99A1D6-23D1-4599-93BE-34BD9B53D732).

BR-REQ-017 — Creazione elemento workflow DEM in stato iniziale

Statement: L'avvio del workflow crea l'elemento DEM nel primo stato: _currentAct.Run(iduser) → dal.RunCreate → DEM_DOCREATEACTIVITY, che scrive ELEMENTWORKFLOWSTATE (con sequence ELEMENTWORKFLOWSTATE_0) e ELEMENTWORKFLOWHISTORY.

Tipo: state-transition · Enforcement: mixed (BL + DB) · Confidence: VERIFIED · customer_specific: false
Evidenza: WorkflowActivity.vb:345-349 (Run → dal.RunCreate(_idworkflow, _idactivity, idactor)); ActivityDAL.vb:247 (DEM.DOCREATEACTIVITY); catalogo: DEM_TEST38,DEM_DOCREATEACTIVITY,PROCEDURE,...,ELEMENTWORKFLOWSTATE,TABLE,RW, ...,ELEMENTWORKFLOWHISTORY,TABLE,WRITE, ...,ELEMENTWORKFLOWSTATE_0,SEQUENCE,REF, ...,ACTIVITY,TABLE,READ.

BR-REQ-018 — Aggancio richiesta↔elemento workflow

Statement: Dopo la creazione dell'elemento DEM, la richiesta viene collegata all'elemento tramite SetWorkflowInterface(newIdElement) → GESTREQUEST.ADDWORKFLOWINTERFACE (tabella REQUESTWORKFLOWINTERFACE). Il collegamento è parte della transazione (precede il Commit).

Tipo: state-transition (integrità) · Enforcement: mixed (BL + DB) · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:214; Request.vb:2596-2600; RequestDAL.vb:5641,5653; catalogo GESTREQUEST,PACKAGE BODY,...,REQUESTWORKFLOWINTERFACE,TABLE,WRITE.

BR-REQ-019 — Calcolo scadenza per ExpireDateMode

Statement: Il calcolo/salvataggio della scadenza dipende da CallType.ExpireDateMode: GLOBALALERT → usa l'alert (AlertID > 0) e calcola la data effettiva via CalculateExpiration2; USERINPUT → usa la data inserita dall'utente (se valida, tra MinValue e MaxValue); ALL → applica alert se presente, altrimenti la data utente. In chiusura, l'eventuale "was expired" è valutato secondo ExpireTarget (ToClose/ToRegister/ToStartView).

Tipo: date-logic / calculation · Enforcement: BL · Confidence: VERIFIED · customer_specific: false
Evidenza: Request.vb:2378-2411 (SetExpiry(writeeffectivedate) con Select Case su ExpireDateModes); Request.vb:2792-2803 (CloseWithExpireSet + Settings.ExpireTarget).
Flag: date-sensitive logic (guardie > DateTime.MinValue AndAlso < DateTime.MaxValue).

BR-REQ-020 — Messaggio iniziale sull'elemento con livello NoLevel

Statement: Alla creazione viene registrato un messaggio iniziale sull'elemento con la descrizione della richiesta e livello messaggio NoLevel.

Tipo: state-transition · Enforcement: BL · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:211 (DEM.ElementMessage.Create(newIdElement, iduser, _objRequest.Description, New List(Of Integer) From {DEM.Constants.MessageLevelsBuiltIn.NoLevel})).
Flag: hard-coded id (MessageLevelsBuiltIn.NoLevel).

BR-REQ-021 — Notifica mail condizionata a MailingType

Statement: L'invio della notifica mail (ProcessAlertSystem) avviene solo se Settings.MailingType <> "none"; il valore "none" disattiva completamente le notifiche del modulo.

Tipo: config-flag · Enforcement: BL · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:232-234 (If Descor.RequestCenter.Configuration.Settings.MailingType <> "none" Then ProcessAlertSystem()); Settings.vb:107-111; CreateUserControlBase.vb:355-359.
Flag: magic string ("none"); flag di configurazione da RequestCenter/Settings.

BR-REQ-022 — Cancellazione protocollo temporaneo in Finally

Statement: Il protocollo temporaneo (tabella PROTOCOLTEMP) viene sempre cancellato nel blocco Finally, indipendentemente dall'esito (commit o rollback): Ticket.Protocol.DeleteTemporaryProtocol(...).

Tipo: state-transition (cleanup) · Enforcement: BL (+DB) · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:253; catalogo GESTREQUEST_T2,PACKAGE BODY,...,PROTOCOLTEMP,TABLE,RW.

BR-REQ-023 — Collegamento a richiesta padre (sub-lavoro)

Statement: Se la creazione avviene in contesto di una richiesta padre (_objRequestParent), il nuovo ticket viene collegato (SetLinked(parent.IdRequest)), viene aggiunto un messaggio sull'attività padre ("SubWorksCreated") e la descrizione riporta il protocollo padre ("OpenedBy").

Tipo: state-transition (gerarchia) · Enforcement: BL · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:176-183; regolato anche da Settings.SubWorksMode (Settings.vb:203-207).

BR-REQ-024 — Calcolo sub-protocollo del figlio

Statement: Per un call type con IdCallTypeParent > 0 e richiesta padre presente, il sub-codice protocollo è calcolato come SubCodeSeparator + (SubCode / 10^ProtocolLevel) formattato a due cifre, concatenato al protocollo padre. La forma finale del protocollo è personalizzabile via CustomRequestCenterProtocol.

Tipo: calculation · Enforcement: BL · Confidence: VERIFIED · customer_specific: true
Evidenza: CreateUserControlBase.vb:1945-1967 (in particolare :1958-1959 subcode = String.Format("{0}{1}", objProtocol.SubCodeSeparator, (objProtocol.SubCode / (Math.Pow(10, objProtocol.ProtocolLevel))).ToString("00"))).
Flag: magic number (10^ProtocolLevel, formato "00"); customer-specific (CustomRequestCenterProtocol parametrico).

BR-REQ-025 — Ritorno protocollo a ScheduleCenter (ODL)

Statement: Se la richiesta è generata da ScheduleCenter (_generatedByAPPREF = strong name "ScheduleCenter") e con _generatedByID numerico valido, il protocollo e l'id della richiesta vengono scritti indietro sull'ODL (SetRCProtocolInOdl).

Tipo: customer-specific (integrazione inter-modulo) · Enforcement: BL · Confidence: SUPPORTED · customer_specific: true
Evidenza: makeTicket.ascx.vb:159-169 (If _generatedByAPPREF.Equals(...GetKeyForStrongName("ScheduleCenter")...) ... schHelper.SetRCProtocolInOdl(IdOdl, _objRequest.Protocol, _objRequest.IdRequest)).
Flag: integration/customer-specific variant.

BR-REQ-026 — Redirect post-creazione (CreationMoment + NavigationSource)

Statement: Il comportamento dopo il salvataggio dipende da: NavigationSource=AutoTicket → ricarica la stessa URL; CreationMoment=Before con runcontinue → apre "Activity Quick Window", altrimenti redirect alla home RequestCenter; CreationMoment=After → repost verso webTicketConfirm.ascx (conferma protocollo).

Tipo: state-transition · Enforcement: UI · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:256 (RedirectAction(runcontinue, Parametric.RequestCenter.Protocol.GetCreationMoment)); CreateUserControlBase.vb:1911-1934.
Flag: hard-coded path (~/requestcenterweb/UserControls/FlowActions/webTicketConfirm.ascx).

BR-REQ-027 — Azioni extra-flusso via WCF

Statement: Il servizio ExtraFlowActionsProxy esegue azioni su ticket esistenti solo se ValidateLoginKey ha successo e se idTicket > 0 AndAlso idActivity > 0; il dispatch usa il tipo attività: per Create/CreateClose (GUID) si usa CreateUserControlBase.ExtraFlowAction, altrimenti FlowUserControlBase.ExtraFlowAction. Login non valido → "Not Authenticated"; parametri non validi/errore → "ERROR5001".

Tipo: permission · Enforcement: mixed (WCF + BL) · Confidence: VERIFIED · customer_specific: false
Evidenza: ExtraFlowActionsProxy.svc.vb:55-124 (If ValidateLoginKey(...) :56,64; If idTicket > 0 AndAlso idActivity > 0 :73; dispatch su ActivityType.GUID = ...Create / CreateClose :93).
Flag: magic string codici ritorno ("ERROR5001", "Not Authenticated"); hard-coded id (GUID Create/CreateClose).

BR-REQ-028 — Valori di default hard-coded alla creazione

Statement: Alla creazione interattiva vengono impostati valori di default fissi: differibilità SetDeferability(0), tipo richiesta SetType(0); per il workflow a singola attività anche SetAlert(0).

Tipo: config-flag (default hard-coded) · Enforcement: BL · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:201-202 (SetDeferability(0) / SetType(0)), :139 (SetAlert(0)).
Flag: magic numbers (0).

BR-REQ-029 — Selezione DAL read-only vs read-write

Statement: L'istanza Request viene costruita passando Settings.DALUseReaders, che determina l'uso di connessioni/reader ottimizzati (lettura) rispetto al path di scrittura; la variante di sola lettura (RequestWF(..., False)) mappa su GETREQUEST (SELECT via ref-cursor, nessuna scrittura).

Tipo: config-flag · Enforcement: BL · Confidence: VERIFIED · customer_specific: false
Evidenza: makeTicket.ascx.vb:115 (New Ticket.Request(RequestCenter.Configuration.Settings.DALUseReaders, ...)); Settings.vb:137-141; variante read-only RequestDAL.vb:31,52 (GETREQUEST).

Sintesi flag di rischio

Regole UI-only (rischio bypass via BL/WCF diretto): BR-REQ-006, BR-REQ-007, BR-REQ-008, BR-REQ-009, BR-REQ-010, BR-REQ-026. La validazione dei campi obbligatori (BR-REQ-007/008) non è ripetuta a livello BL/DB: l'entry point Request.Create è condiviso da portale/WCF/helper (reverse-trace FLOW-REQ-001) e non riapplica tali controlli.
Regole DB-only (integrità garantita solo lato Oracle): BR-REQ-014 (radice REQUESTREGISTRY), parzialmente BR-REQ-017/018 (sequence + write). Vincoli/trigger puntuali non ispezionati — vedi open questions.
Hard-coded ids / magic: GUID call type (BR-REQ-003), GUID Create/CreateClose (BR-REQ-016, BR-REQ-027), NoLevel (BR-REQ-020), Count = 1 (BR-REQ-016), 10^ProtocolLevel (BR-REQ-024), stringhe "none" (BR-REQ-021) e codici "ERROR5001"/"Not Authenticated" (BR-REQ-027), default 0 (BR-REQ-028), path webTicketConfirm.ascx (BR-REQ-026).
Feature flag nascosti / parametrici: GetCreationMoment e i suffissi protocollo (BR-REQ-004/005) risolti a runtime dal motore DynamicParametric (Evaluating.Instance.EvalAsync); HeavyLoadMode, MailingType, DALUseReaders, SubWorksMode, ExpireTarget da RequestCenter/Settings.
Date-sensitive: BR-REQ-019 (calcolo scadenza, guardie MinValue/MaxValue).
Customer-specific: BR-REQ-004, BR-REQ-005, BR-REQ-024 (protocollo parametrico), BR-REQ-025 (integrazione ScheduleCenter).

Open questions

Vincoli/trigger effettivi su REQUESTREGISTRY/REQUESTREGISTRYDATA e mappatura puntuale della proc ADDREQUEST (il catalogo aggrega a livello package body).
Ramo CreationMoment=Before: punto esatto di generazione protocollo (presumibilmente in Page_Load/pre-render) non tracciato in questa estrazione.
Comportamento in configurazione PROD (osservato solo ambiente TEST38).
Tabelle DEM toccate da ElementMessage.Create (BR-REQ-020) non mappate nel catalogo.

Table of Contents