La funazione è la BCD__editPostPrepare in quanto spostarlo significa allestire il record come se si stesse per salvare una modifica (che non c’è) e poi salvarlo nel database storico.
Al termine di questa azione il sistema deve immediatamente cancellare in modo definitivo il record sul lato del database live.
Per fare questo viene quindi richiamata la BCD__editPostPrepare con speciale chiave|valore > destination: ‘toArchive‘.
Al momento in cui si elabora la preparazione dell’oggetto ci si prepara quindi anche a salvarlo, procedura che viene ovviamente effettuata con BCD__saveRecord alla quale viene aggiunta una chiave|valore > form: ‘noFormButFullArchive‘.
Quando la BCD__saveRecord si trova a salvare il record comprende quindi che il salvataggio è sul database di archiviazione. Al ritorno, lo stesso codice innesca un meccanismo di eliminazione permanente del recor appena spostato tramite la una chiave|valore > why: ‘afterFullArchive‘ che dice semplicemente alla funzione di comunicare un messaggio diverso e specifico al termine dell’eliminazione.
Allegati
[Aggiunta del 05.06.2023]. Al momento della popup di archiviazione storica del record, viene effettuato un controllo sulla presenza o meno di allegati. Qualora presenti si offre all’utente la possibiltà di accedere agli allegati e scaricarli in posizione locale. Al contempo di offre una checkbox che definisce che l’utente ha preso visione degli accadimenti a seguito di un mancato download e di un’archiviazione storica.
Nota: al momento non c’è una reale eliminazione degli allegati, questa deve essere sviluppata quando, al quarto trimestre di TS si procederà a rendere opzionale il futuro degli allegati a seguito di archiviazione storica. Alcune aziende potrebbero voler lasciare gli allegati presenti online, altre procedere opzionalmente al download ed eliminazione. Vero è che la procedura richiede sicuramente più tempo e attenzioni per cui ad oggi, 05.06.2023, la si tiene in sospeso, perfettamente funzionante ma senza reale eliminazione degli allegati.