--- title: Centru de upgrade — analizează, planifică și actualizează în siguranță instalarea TSync description: Ghid prietenos pentru Centrul de upgrade TSync (TLMP). Vezi pe ce versiune ești și cât e de sănătoasă, primești un plan de upgrade sigur, faci backup, îl rulezi în gol (dry-run) și — doar când decizi tu — execuți, recuperezi sau faci rollback. Nimic nu rulează automat. product: TSync Intelligence 11.3.6 language: ro canonical: https://docs.tsync.pro/ro/modules/tsync-lifecycle/ source: https://docs.tsync.pro/llms.txt --- # 🚀 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.