🚀 Centru de upgrade

Centrul de upgrade este camera ta de control pentru a înțelege și a actualiza în siguranță această instalare TSync. Se uită la ce ai, îți spune cât e de sănătoasă, construiește un plan de upgrade pas cu pas, îți permite să-l repeți fără să schimbe nimic și — doar când decizi tu — îl rulează, cu backup și rollback pregătite.

Îl deschizi din Setări → Centru de upgrade, sau din Centru de configurare → Sistem.

Regula de aur: Centrul de upgrade nu schimbă niciodată nimic de capul lui. Orice acțiune care ar putea modifica date e ceva ce pornești tu, după un backup, și majoritatea pot fi rulate în gol (dry-run) întâi, cu zero modificări.

Ce-ți spune dintr-o privire

Prezentarea generală arată, în limbaj clar:

  • Generație & versiune — dacă instalarea e legacy, tranzițională, modernă sau enterprise, versiunea detectată și ținta.
  • Sănătate — un scor 0–100 (folosește aceleași verificări ca poarta de release).
  • Compatibilitate & risc — poți face upgrade în siguranță acum, care e nivelul de risc și de ce (factori în limbaj clar, ex. „module necunoscute" sau „codul implementat e mai nou decât baza de date").
  • Mediu & set de caractere — mediul detectat plus o verificare rapidă utf8mb4 a bazei de date (codarea pe care o așteaptă TSync modern), ca o bază veche doar-utf8 să fie observată înainte de upgrade.
  • Următoarea acțiune recomandată — o singură frază clară despre ce să faci în continuare.

Există și un buton Rulează analiză (salvează un instantaneu) și un Export pentru un fișier de diagnostic pe care îl poți trimite la suport.

Componentele

Detecție & analiză

Citește semnalele proprii ale instalării (migrarea aplicată vs implementată, module, mediu) și o clasifică. Doar-citire.

Amprentă (fingerprint)

Ia un instantaneu structural (tabele, module, chei de opțiuni, stare migrări) — doar metadate, niciodată datele tale de business, secretele excluse. Capturează una înainte de upgrade și compară mai târziu ca să vezi exact ce s-a schimbat. Exportul de suport împachetează o versiune redactată (fără secrete, fără rânduri de business) pentru suport, la unul din trei niveluri de redactare — basic, strict (implicit) sau maximum — ca să alegi cât de mult detaliu împărtășești.

Module, Capabilități & Drift

  • Inventar module — fiecare modul, versiunile lui și dacă ceva a deviat.
  • Inventar capabilități — ce funcții (contabilitate, trezorerie, API REST, …) sunt prezente, parțiale sau oprite.
  • Drift — o listă clară de nepotriviri (un modul pe disc dar neînregistrat, un tabel lipsă, cod implementat mai nou decât baza de date) cu cât de reparabilă e fiecare.
  • Foldere de installer rămase în urmă — vezi mai jos.

Foldere de installer rămase în urmă

De fiecare dată când implementezi o versiune nouă, folderul installerului este redenumit, nu șters (din install în ceva de forma install_20260807_014630). Este intenționat: un upgrade care șterge fișiere este un upgrade care poate șterge fișierele greșite. Efectul secundar e că fiecare implementare lasă pe server încă o copie completă a installerului — inofensivă, dar fiecare copie conține în continuare un fișier database.sql.

Pagina Drift le listează acum, arătând pentru fiecare folder dimensiunea, câte fișiere conține și dacă are database.sql. Lângă fiecare este un buton Șterge.

Două lucruri la care să te aștepți:

  • Cel mai recent folder rămas nu este niciodată oferit spre ștergere. E copia de care ar avea nevoie o revenire la versiunea anterioară, așa că e marcat păstrat și nu are buton. Curățenia nu te poate lăsa niciodată fără niciuna.
  • Ștergi un singur folder odată, iar fiecare apăsare cere confirmare. Nu există buton „șterge tot", iar o ștergere nu poate fi anulată.

Dacă un folder e marcat nu poate fi scris de serverul web, permisiunile de la găzduire împiedică ștergerea — șterge-l prin FTP sau cere ajutorul furnizorului. Dacă există un folder install viu, pagina te avertizează: zona de administrare rămâne blocată cât timp el există, deci întâi finalizează sau elimină instalarea.

Compatibilitate & Risc

Transformă tot ce e mai sus într-o decizie (suportat, suportat cu reparație, necesită checkpoint, revizuire manuală, blocat) și un nivel de risc cu scoruri contributive denumite.

„Eligibil producție: NU" îți spune acum de ce

Prezentarea răspundea la întrebarea asta cu un scor — 73/100, 0 blocante, 49 avertismente — chiar pe mașina care este producția. Verdictul nu era greșit, era inutilizabil: numea un număr în loc de constatările care îl decideau.

Aritmetica e toată constatarea. Scorul pornește de la 100 și pierde 30 de puncte pe blocant și 4 puncte pe avertisment de client, iar producția cere 95 sau mai mult. Două avertismente de client — oricare două — ajung ca o instalare să fie neeligibilă.

Motivul le numește acum: grupate pe regulă, cel mult cinci, cu restul declarat ca „+N altele". Blocantele apar primele, fiindcă fiecare costă treizeci de puncte. Lista completă a constatărilor numărate călătorește cu datele de sănătate, mărginită la 25 — o listă pe care n-o poate citi nimeni e la fel cu nicio listă.

Pragul și ponderile nu s-au schimbat, intenționat. Regula a fost întărită după ce o instalare cu sănătate 63 și trei derive critice de schemă se raporta singură ca eligibilă pentru producție. Slăbirea unei porți de siguranță ca să se citească mai bine un ecran e chiar felul în care se întoarce acel defect.

Fluxul de upgrade sigur

  1. Plan — Centrul construiește un plan ordonat (backup → verificări → reparații → upgrade bază de date → validare). Fiecare pas arată riscul și dacă poate fi inversat.
  2. Dry-run — repetă tot planul. Raportează ce s-ar întâmpla și face zero modificări.
  3. Backup — creează un backup verificat al bazei de date (verificat ca dimensiune și checksum, stocat într-un folder protejat). Upgrade-urile cu risc mare și de producție sunt blocate până există un backup bun. Pe găzduire partajată unde backup-ul integrat nu poate rula, poți în schimb să certifici un backup extern — înregistrezi cel pe care l-ai făcut tu în StackCP, phpMyAdmin sau prin SSH (metoda, numele fișierului, dimensiunea, opțional checksum-ul și o notă). Doar consemnează că există un backup verificat, ca să satisfacă poarta de backup; nu atinge niciodată baza ta de date și nu oferă restaurare din el.
  4. Aprobare — o persoană revizuiește și aprobă planul. Pentru producție e o poartă în doi pași: cineva solicită mai întâi aprobarea de producție, iar o a doua persoană cu permisiunea de producție o acordă. Ambii pași sunt înregistrați în jurnalul de audit, deci aceeași persoană nu-și poate aproba pe ascuns propriul upgrade de producție.
  5. Execuție — rulează planul, întâi pe staging pentru orice e riscant, apoi producție. Monitorul de execuție arată progresul fiecărui pas. Pașii siguri rulează; orice ar atinge date într-un mod care nu e complet verificat se oprește și te așteaptă.
  6. Validare — după o rulare, o poartă de finalizare confirmă sănătate ≥ 95, zero blocaje și zero drift critic și compară o amprentă proaspătă cu cea de dinainte de upgrade — semnalând orice neașteptat.

Dacă ceva merge prost

  • Recuperarea mută o instalare pe jumătate terminată sau cu drift înainte, către o stare consistentă (poate reînregistra un modul ale cărui fișiere sunt prezente dar înregistrarea s-a pierdut, de exemplu). Rulează doar reparațiile automate sigure și oprește restul.
  • Rollback-ul revine la o stare anterioară: inversează schimbările sigure la nivel de metadate, iar pentru schimbări de schemă/date te trimite la backup-ul verificat. Restaurarea verifică backup-ul și îți dă comanda exactă — nu suprascrie niciodată baza ta live de capul ei.

Pentru administratori — linia de comandă

Totul e disponibil și din CLI (UI-ul și CLI-ul folosesc același motor):

php index.php tsync lifecycle detect
php index.php tsync lifecycle analyze
php index.php tsync lifecycle fingerprint
php index.php tsync lifecycle drift
php index.php tsync lifecycle compatibility
php index.php tsync lifecycle risk
php index.php tsync lifecycle plan
php index.php tsync lifecycle dry-run
php index.php tsync lifecycle backup
php index.php tsync lifecycle execute --mode staging
php index.php tsync lifecycle recover --mode dry_run
php index.php tsync lifecycle rollback --mode dry_run
php index.php tsync lifecycle restore
php index.php tsync lifecycle validate
php index.php tsync lifecycle status

Flag-urile sunt separate prin spațiu (--mode staging, nu --mode=staging).

Bine de știut

  • Nimic nu rulează automat — nu există mod autonom. Un om pornește fiecare schimbare.
  • Backup întâi — upgrade-urile riscante și de producție nu pornesc fără un backup verificat.
  • Totul e auditat — analize, planuri, aprobări, execuții, reparații și rollback-uri sunt toate înregistrate.
  • Permisiuni — vizualizarea, analiza, aprobarea și execuția sunt permisiuni separate, deci poți lăsa oamenii să vadă analiza fără să-i lași să ruleze un upgrade.

Legacy Bridge

Upgrade Center funcționează și ca Legacy Bridge pentru instalări vechi v3.4. Nu promite rularea ca atare a fiecărui modul vechi — promite să detecteze, inventarieze, protejeze, migreze sau arhiveze datele legacy în siguranță.

Ecranele pe care le folosești (Setup → Upgrade Center):

  • Legacy Bootstrap — pregătește o instalare veche: inventariază modulele, salvează un fingerprint de referință, construiește sugestiile de alias legacy→modern și puntea de schemă. Complet sigur: nu șterge niciun modul și nu modifică datele de business. „Simulare" arată ce ar face, cu zero modificări. Tabelul de alias de module e locul unde confirmi cum se mapează fiecare modul vechi la echivalentul modern: pentru fiecare sugestie poți Aproba, Păstra separat sau — odată aprobat — Activa modulul modern ca să preia el. Nimic nu se activează automat; decizi tu fiecare mapare, iar fiecare alegere e auditată.
  • Checkpoints — pașii ordonați de la o instalare legacy până la versiunea curentă. Fiecare rulează doar după precedentul; pasul final nu rulează niciodată prematur.
  • Migratoare — pe zone vezi câte date legacy există și cum se mapează la modulele moderne. Rularea unui migrator transformă datele legacy în modulele moderne — contabilitate (plan de conturi și note contabile), depozit, HR, mijloace fixe, furnizori și producție. Este idempotent (a doua rulare nu duplică), non-distructiv (tabelele legacy rămân read-only) și complet auditat. Nu inventează cifre: o notă contabilă dezechilibrată, un rând nemapat sau orice e ambiguu este marcat pentru revizuire, niciodată ghicit. Ordinele de producție deschise sunt puse pe pauză (nu rulează automat după upgrade), iar istoricul de salarizare și fiscal este păstrat exact, niciodată recalculat. Panoul Inteligență mapare câmpuri arată strategia fiecărei zone și, după o rulare, paritatea (rânduri legacy vs migrate).
  • Furnizori & documente de achiziții — migratorul de furnizori aduce furnizorii legacy cu contactele și catalogul lor de prețuri, iar acum și comenzile de achiziție și facturile de furnizor (cu liniile lor). Fiecare document este atașat furnizorului modern corect, fiecare factură este legată de comanda sa, valuta este rezolvată la codul ISO și sumele sunt păstrate. Deschide Migratoare → Detalii furnizori pentru a vedea, pe furnizor, contactele, articolele, comenzile și facturile migrate — și o notă clară când nu există documente legacy de migrat.
  • Module client cumpărate (add-on) — Upgrade Center recunoaște acum add-on-urile terțe uzuale pe care un client le-a cumpărat pentru instalarea veche (HR payroll, HR profile, file sharing, feedback, video library și support contact) și poate mapa câmp-cu-câmp datele lor în modulul TSync corespunzător — TSync HR Payroll, TSync HR Records, File Hub, TSync Project Feedback, TSync Academy și widget-ul de contact Omnichannel. Fiindcă aceste add-on-uri își țin datele în tabele cu nume diferite, rândurile lor sunt transformate în tabelele moderne (valorile păstrate, niciodată recalculate), nu lăsate în urmă. După o migrare verificată, tabelele vechi sunt păstrate read-only în arhivă. Doar un modul custom cu adevărat necunoscut este arhivat fără migrare.
  • Arhivă legacy — ce nu este migrat (un modul custom cu adevărat necunoscut sau istoricul fiscal/de salarizare păstrat exact ca atare) e păstrat aici, read-only, cu numărul de rânduri și export CSV. Add-on-urile client recunoscute (de mai sus) sunt migrate câmp-cu-câmp întâi, nu doar arhivate. Nimic nu se editează sau șterge; poți adăuga note.

Instalare curată vs upgrade. Dacă instalarea e aproape goală, Upgrade Center recomandă o instalare curată pe versiunea curentă în loc de o migrare legacy grea — poți rula totuși analiza mai întâi.

Important: upgrade-urile legacy de producție trec mai întâi prin staging (cu backup validat și aprobare). Migrarea câmpurilor este verificată pe structura reală a bazei tale de date; verificarea finală a datelor rulează pe copia de staging înainte de producție. Nimic nu rulează automat, iar o simulare face zero modificări.