Dolibarr Visual Changelog: a frissítés üzleti nyelven

2026. augusztus 28. · Közösség

A changelog, amit nem csak a fejlesztők értenek: itt a Dolibarr Visual Changelog

A friss hivatalos közösségi projekt képekkel és üzleti kategóriákkal fordítja le a Dolibarr v23 és v24 technikai változáslistáját. Megnéztük, miért több ez egyszerű szépítésnél.

← Vissza a blogbejegyzésekhez

A Dolibarr hivatalos GitHub-szervezetében megjelent egy külön Visual Changelog projekt, amely a hosszú, fejlesztői változáslistát képes, kategorizált és előnyközpontú kiadási útmutatóvá alakítja. Első látásra ez csak kényelmesebb release note-nak tűnik. Valójában egy régóta fennálló ERP-problémára ad választ: hogyan döntsön egy cég a frissítésről, ha a változások többsége commitok és technikai rövidítések formájában érkezik?

Mit csinál másként?

A projekt saját leírása szerint a nyers fejlesztői changelogot közérthető, üzleti előnyökre fókuszáló kártyákká alakítja. A jelenlegi adattár a Dolibarr v23 és v24 változásait kezeli, a tartalmat pedig olyan csoportokba rendezi, mint az AI és innováció, könyvelés és számlázás, értékesítés és logisztika, HR, felhasználói felület, valamint regressziók és figyelmeztetések.

Egy változás egyetlen strukturált rekordként szerepel: stabil technikai azonosítót, sorrendet, kategóriacímkéket, fordításokat, képeket és opcionális forráshivatkozásokat kaphat. A megjelenítő ezekből nyelv és kategória szerint építi fel a nézetet. Ez jóval követhetőbb, mint ugyanazt az újdonságot több, egymástól elszakadó nyelvi listában karbantartani.

A v24-adatfájl megmutatja, miért hasznos

A Visual Changelog v24-es adatában külön kártyát kap többek között a kísérleti AI-asszisztens és MCP-szerver, a hibajegyek AI-helyesírás-ellenőrzése, a pénzforgalmi és eredményszemléletű könyvelési mód közötti választás, az ismétlődő számlák automatikus e-mail-küldése, a WebPortal bővítése és a raktárközi átadás stabilizálása.

Ez ugyanazokat a változásokat nem technikai műveletként, hanem használati helyzetként mutatja meg. Egy raktárvezetőnek például nem egy pull request száma a döntő, hanem az, hogy követhetőbbé válik-e a belső árumozgás. Egy pénzügyi vezetőnek pedig az számít, milyen könyvelési folyamatot érint a frissítés.

Három dolog, amitől ez több egy látványos funkciólistánál

1. Közös beszélgetési alapot ad. A rendszergazda, a fejlesztő és a folyamatgazda ugyanarról a kártyáról indulhat, miközben mindegyikük más kockázatot vizsgál.
2. Elválasztja a tartalmat a felülettől. A verziók JSON-adatfájlban vannak, a felület pedig dinamikusan tölti be őket. Így egy új verzió vagy fordítás hozzáadásához nem kell minden nézetet újraépíteni.
3. Megőrzi a technikai visszautat. A rekordokhoz teljes changelog, videó, képernyőkép vagy változásszintű link kapcsolható. A közérthetőség így nem feltétlenül jelenti a bizonyíthatóság elvesztését.

Ami még hiányzik — és éppen ezért érdekes nekünk

A repository jelenlegi README-je angol, francia, görög és spanyol nyelvi támogatást sorol fel; magyar fordítás egyelőre nincs a felsorolásban. Ez kézzelfogható közösségi lehetőség: nem pusztán menüpontokat kellene lefordítani, hanem a változások üzleti értelmét kellene pontos, természetes magyar nyelven megfogalmazni.

A jó magyar változatnál három szabály lenne fontos:

• különüljön el a stabil funkció, a kísérleti lehetőség és a regressziós figyelmeztetés;
• a fordítás ne ígérjen többet, mint amit a hivatalos release és a forráskód igazol;
• a magyar jogi vagy számlázási megfelelőséget ne vezesse le egy általános nemzetközi funkcióleírásból.

Így használnánk egy valódi frissítési projektben

1. A vizuális listából kiválasztjuk az érintett üzleti területeket.
2. A kiválasztott kártyákat összevetjük a teljes GitHub-release-szel és a futó verzióval.
3. Leltárba vesszük az érintett külső modulokat, egyedi fejlesztéseket, jogosultságokat és integrációkat.
4. Tesztkörnyezetben szerepkörönként végigpróbáljuk a kritikus folyamatokat.
5. Csak ezután születik döntés az éles frissítésről és annak visszaállítási tervéről.

A Visual Changelog tehát nem teszi kockázatmentessé a verzióváltást. Ennél fontosabbat tesz: érthetővé teszi, miről kell közösen dönteni. Egy ERP-frissítés akkor lesz üzleti projekt, amikor a technikai változásokat a napi munkához, felelősökhöz és ellenőrizhető tesztekhez tudjuk kötni.

Források

• Dolibarr Visual Changelog – hivatalos GitHub-repository, célok, struktúra és nyelvi támogatás
• A Visual Changelog Dolibarr v24 strukturált adatfájlja
• Dolibarr 24.0.0 – teljes hivatalos kiadási jegyzet

Forrásállapot: 2026. augusztus 28. A Visual Changelog közösségi projekt és folyamatosan változhat; frissítési döntésnél mindig a célverzió teljes kiadási jegyzete, a forráskód és a saját teszt eredménye az irányadó.

Ez a Dolibarr.hu szerkesztett, magyar nyelvű útmutatója.