Verzování obsahu

jNetPublish eviduje všechny verze assetového obsahu, které vznikají editorskými postupy. Tento princip je shodný pro OG i NG, rozdíly jsou jednak v některých detailech práce s assety, zejména ale v NG přibývá verzování datového slovníku.

CMS slouží zároveň jako nástroj pro správu verzí: umožňuje připravovat různě velké sady změn, které se mohou nezávisle na sobě slučovat.

CMS podporuje přenosy změn mezi jednotlivými servery: nejběžnější přenos změn je publikace (přenos sady změn z editačního na publikační server). V OG je to jediná možnost automatického přenosu. (Pro všechny ostatní případy je nutné použít buď hrubé nástroje jako je přenos celé databáze a souborového systému, nebo naopak polomanuální přenosy s vyuitím XML exportů a importů assetů.)

V NG je možná pokročilejší synchronizace pomocí klonování projektů - NG funguje jako svého druhu distribuovaný systém, s možností přenosů mezi produkčními a neprodukčními prostředími.
 

CMS používá konzistentně specifickou terminologii pro práci s verzemi: jeden nedělitelný blok změn se označuje jako transakce.

Větší soubory změn jsou sezení a projekty. Sezení a projekt jsou v obou případech soubory transakcí a v mnohém jsou si podobné. Předběžné rozlišení: Sezení jsou změny v rozsahu, jaký připraví v krátkém časovém rozmezí jeden uživatel.

Projekt jsou změny velkého rozsahu, připravované po dobu více než jednoho dne a/nebo více než jedním uživatelem.

První přiblížení představě, co je transakce: je to nedělitelná sada změn odpovídající jedné akci uživatele v administraci.

(Toto je skutečně jen přiblížení: jedna akce uživatele může vygenerovat i několik transakcí.)

To znamená, že transakcí je například vytvoření položky nebo uložení změn v položce. Další transakce mohou zahrnovat libovolný počet položek: sem patří kopírování, přesuny a mazání položek. Transakcí je i založení sezení a potvrzení změn ze sezení nebo z projektu.

Sezení je blok změn sdružující několik úprav, které provedl jeden uživatel. Podobá se v několika ohledech projektu: je součástí stromu projektů, má náhledovou URL apod.

Zakládá se automaticky s první změnou, kterou uživatel provedl - pokud v daném projektu sezení aktuálně nemá. Sezení může mít v každém projektu, ale jen jedno.

Sezení je na rozdíl od projektu přístupné jen uživateli, který ho založil - jiný uživatel tedy nemůže do sezení přidávat své změny ani nemůže sezení uložit. Je ale možné pracovat v tomto sezení, pokud se přihlásíte jako jeho vlastník. Je také možné vygenerovat náhledovou URL, která je přístupná pro všechny uživatele.

Pokud má uživatel změněnou položku v sezení, které dosud nebylo uzavřeno, je pro ostatní uživatele v daném projektu (a v OG i v jeho nadprojektech) zamčená - nelze ji upravovat.
 

• Hierarchické uspořádání
• Kořenový projekt = veřejný stav
• Spolupráce mezi uživateli
• Přístup řídí ACL

jNP při vykreslování stránky musí mít informaci nejen o tom, který článek se zobrazuje, ale také potřebuje znát projekt (nebo sezení), ze kterého má brát verze všech položek.

Dobře je to vidět na náhledových URL. Tyto URL obsahují identifikátor projektu nebo sezení. Umožňují podívat se na výslednou podobu stránky v projektu nebo sezení i těm uživatelům, kteří nejsou přihlášení nebo dokonce vůbec nemají účet v administraci. (Struktura URL se mezi OG a NG liší. V OG náhledová URL zároveň slouží jako URL insite editace.)

Pokud je uživatel přihlášený do administrace, drží se identifikátor projektu nebo sezení v session. Proto přihlášený uživatel vidí verzi stránek v projektu nebo sezení i na normální (nenáhledové) URL.

• Zamykání změněné položky všude mimo podprojekty
• Automatická viditelnost změn v podprojektech
• Potvrzování změn do nadprojektu přímo

• Nezamyká se v jiných podprojektech
• Možnost konfliktních změn
• V projektu může vzniknou jiná verze slovníku
• Netriviální přenos změn do podprojektu
• Potvrzování i slučování změn přes sezení

Za určitých podmínek je možné vyžádat si ze seznamu assetů potvrzení jedné konkrétní položky. Toto je dobré dělat jen v případě, že dobře víte, co děláte: potvrzení konkrétní položky může vynutit potvrzení dalších položek.

Druhý extrém je potvrzení všech zbývajících změn v projektu: toto se provádí ze správy projektů.

Třetí, nejspolehlivější je prostřední: potvrzení změn přes specializovanou administraci umožňující vybrat konkrétní položky a pak teprve změny potvrdit.

Jednotlivé způsoby potvrzování změn projektů se dají zpřístupnit konkrétním skupinám uživatelů na základě jejich rolí. K tomu slouží speciální panel ve správě projektů.

• Sloučení probíhá v obou směrech
• Nejprve "sloučení", pak "potvrzení"
• Nejprve je třeba mít shodný slovník

• Přehled: konfliktní - změněné - nové
• Hromadné potvrzení vytvoří sezení
• Pak se řeší konflikty
• Následně se musí potvrdit sezení

• Načasované potvrzení změn
• Zamkne projekt

• plánované potvrzení
• automatické slučování
• konflikty řeší správce projektu

• Lze zobrazit historickou verzi položky
• Nelze jednoduše zobrazit minulou podobu stránky
• Lze oživit historickou verzi položky

• Vrácení transakce
• Ořez historie

Je možné na jednom prostředí vytvořit projekt, který je klonem zvoleného projektu na jiném prostředí. Tímto způsobem lze zajistit obousměrnou automatickou synchronizaci změn mezi dvěma prostředími. Díky tomu není potřeba například změny připravené na vývojovém prostředí ručně přenášet na produkci.

Aby toto dobře fungovalo, je třeba postupovat vyzkoušeným způsobem a držet se dále popsaných pravidel.