Divi redaktori labo vienu CMS ierakstu: kā novērst izmaiņu pārrakstīšanu

CMS rediģēšanas konfliktu droši risina, saglabāšanas brīdī pārbaudot ieraksta versiju un apturot izmaiņas, kas balstītas novecojušā kopijā. Redaktoram vienlaikus jāredz, ko mainījis kolēģis, un jāsaglabā iespēja atgūt savu darbu. Paziņojums, ka ierakstu atvēris vēl kāds, viens pats nepasargā no pārrakstīšanas.

Iedomāsimies satura komandu, kas vienā pēcpusdienā precizē pakalpojuma aprakstu. Viens redaktors izlabo cenu nosacījumus, otrs tajā pašā ierakstā papildina virsrakstu. Abi strādā rūpīgi, taču otrais ir atvēris vecāku kopiju. Pēc viņa saglabāšanas cenu nosacījumi atgriežas iepriekšējā redakcijā. Saskarne rāda veiksmīgu saglabāšanu, tāpēc kļūdu pamana tikai pēc publicēšanas.

Problēma ir saglabāšanas līgumā starp pārlūku un serveri. To var pārbaudīt ar reproducējamu scenāriju, nevis minējumu par redaktoru uzmanību. Šis raksts palīdz sagatavot šādu pārbaudi un pieņemšanas prasības esošas vai individuāli izstrādātas CMS uzlabošanai.

Kur pazūd kolēģa labojums

Atverot ierakstu, pārlūks saņem tā saturu. Kamēr cilvēks raksta, serverī var būt saglabāta jaunāka versija. Ja pārlūks vēlāk aizsūta visu sākotnējo ierakstu kopā ar savām izmaiņām, serverim jāspēj atšķirt aktuālu labojumu no vecas kopijas atgriešanas.

Ar atjaunošanas datuma parādīšanu nepietiek. Datums var būt redzams tikai informatīvi, bet saglabāšana joprojām pieņemt jebkuru iesūtīto saturu. Jautājums izstrādātājam ir konkrēts: vai serveris atsaka novecojušas versijas rakstīšanu arī tad, ja lietotāja saskarne pārbaudi neizpilda?

Konfliktu var radīt arī viena cilvēka atvērtas pārlūka cilnes. Vēl viens rakstītājs var būt imports, integrācija vai automātiska datu atjaunošana. Ja aizsardzība darbojas tikai starp redzamajiem CMS lietotājiem, citā saglabāšanas ceļā tā var pazust. Pārbaudē jāiekļauj visi ceļi, kas maina attiecīgo ierakstu.

Vispirms vienojieties arī par aizsargājamo vienību. Tā var būt visa satura lapa, atsevišķa valodas versija vai noteikts datu bloks. Pārāk plaša vienība rada nevajadzīgus konfliktus. Pārāk sīka ļauj savienot savstarpēji nesaderīgus laukus, piemēram, cenu un tās spēkā stāšanās nosacījumu.

Versijas pārbaude saglabāšanas brīdī

HTTP piedāvā nosacītu saglabāšanu ar If-Match. Klients nosūta iepriekš saņemto ETag, un serveris pārbauda, vai tas atbilst aktuālajai reprezentācijai. Ja nosacījums nav izpildīts, tipiska atbilde ir 412 Precondition Failed. Mehānisms un stiprā salīdzinājuma prasība aprakstīta MDN If-Match dokumentācijā.

CMS var izmantot arī savu versijas lauku, ja tam ir līdzvērtīga droša saglabāšanas loģika. Svarīgs ir rezultāts: pārbaude un izmaiņas nedrīkst atstāt starpā iespēju citam pieprasījumam nepamanīti pārrakstīt ierakstu. Konkrēto datubāzes vai lietotnes mehānismu izvēlas izstrādātājs atbilstoši esošajai sistēmai.

ETag identificē reprezentācijas versiju; tas nav cilvēka vārds vai piekļuves atļauja. Autentifikācija un tiesību pārbaude joprojām vajadzīga atsevišķi. Arī versijas marķiera aprēķinam jāatbilst tam, ko saglabājat. Ja tas neatspoguļo aizsargāto lauku izmaiņas, salīdzinājums nenovērsīs attiecīgo konfliktu. MDN ETag skaidrojums.

Nedrīkst aizstāt konkrētas versijas pārbaudi ar vispārīgu nosacījumu, ka ieraksts eksistē. Piemēram, If-Match: * nav pierādījums tam, ka redaktors strādāja ar pašreizējo saturu. Savukārt pārbaude tikai pārlūkā nevar garantēt servera saglabāšanas drošumu. Nosacījumu izvērtēšanu pirms metodes darbības nosaka HTTP semantikas specifikācija.

Brīdinājums, bloķēšana vai sadarbīga rediģēšana

Brīdinājums par citu redaktoru ir noderīgs koordinācijai. Tas palīdz izlemt, vai darbu sākt tagad. Taču kolēģa sesija var beigties bez korektas aizvēršanas vai savienojums var pārtrūkt. Klātbūtnes indikators nedrīkst kļūt par vienīgo datu aizsardzību.

Ekskluzīva bloķēšana var būt piemērota īsam, atbildīgam labojumam, kuru vienlaikus drīkst veikt viens cilvēks. Tad jāparedz, kad bloķējums beidzas, kā to atjauno aktīva sesija un kurš drīkst pārņemt iestrēgušu darbu. Pēc bloķējuma zaudēšanas vecā sesija nedrīkst turpināt saglabāt tā, it kā joprojām būtu vienīgā.

Optimistiskā bloķēšana ļauj cilvēkiem strādāt paralēli un pārbauda konfliktu saglabājot. Tā ir lietojama, ja konflikti nav pastāvīgi un saskarne palīdz tos atrisināt. Ja komanda katru dienu vienlaikus raksta vienā tekstā, var būt pamatota sadarbīga rediģēšana. Tās ieviešana ir plašāks uzdevums nekā vienkāršs brīdinājuma logs.

Izvēli var izdarīt pēc darba rakstura. Vai redaktori parasti labo neatkarīgus laukus? Vai viņiem vajadzīgs kopīgs teikums reāllaikā? Cik bīstama ir nepareizi savienota cena un apraksts? Nav jāievieš sarežģītākais režīms, ja drošu rezultātu dod saprotama versijas pārbaude un konflikta atrisināšana.

Ko cilvēkam parādīt konflikta brīdī

Paziņojumam jāpasaka, ka darbs nav saglabāts, kāpēc tas noticis un ko var darīt tālāk. Piemēram: “Ieraksts kopš atvēršanas ir mainīts. Jūsu teksts ir saglabāts kā lokāla darba kopija. Salīdziniet izmaiņas pirms atkārtotas saglabāšanas.” Lokālas kopijas solījumu drīkst rādīt tikai tad, ja tā tiešām droši izveidota.

Salīdzināšanai noder sākotnējā, aktuālā un paša redaktora versija. Ja parāda tikai divus pēdējos tekstus, cilvēkam var būt grūti saprast, kura atšķirība ir viņa un kura kolēģa veikta. Saskarnē jāizceļ konkrētie lauki, nevis jāprasa pārlasīt visu lapu bez orientieriem.

Neatkarīgas izmaiņas dažādos laukos dažkārt var apvienot automātiski. Tomēr vienāds lauka nosaukums nav vienīgais saistības mērs. Produkta nosaukums, attēls un specifikācija var aprakstīt vienu komplektu. Drošās apvienošanas noteikumi jānosaka pēc satura nozīmes, saglabājot cilvēka lēmumu neskaidros gadījumos.

Ar pogu “Pārrakstīt visu” jābūt īpaši piesardzīgiem. Ja šāda darbība vispār vajadzīga, parādiet, kuru aktuālo versiju tā aizstās, un saglabājiet atjaunojamu vēsturi. Pēc salīdzinājuma arī pa šo laiku serverī var būt jauns labojums. Apvienotās versijas saglabāšanai nepieciešama jauna aktualitātes pārbaude.

Divu redaktoru scenāriju matrica

Tālāk ir piedāvāts pieņemšanas pārbaudes paraugs. Tas neapraksta kādas konkrētas CMS gatavas funkcijas. Izmantojiet testa ierakstu un divas neatkarīgas sesijas, lai pārbaude pati neizmainītu publicētu uzņēmuma informāciju.

Katram testam pierakstiet sesiju secību, sākuma versiju, nosūtīto darbību un servera rezultātu. Ekrānattēls ar brīdinājumu ir noderīgs, bet nepierāda, ka datubāzē nekas nav pārrakstīts. Pārbaudiet arī faktiski saglabāto saturu un vēsturi pēc atsvaidzināšanas.

Automātiska saglabāšana nedrīkst paslēpt kļūmi

Redaktoram jāatšķir rakstīšana lokāli, nosūtīšana, servera apstiprināta saglabāšana un konflikts. Ja visas šīs situācijas apzīmē viens ķeksītis, cilvēks nevar zināt, vai drīkst aizvērt cilni. Īss stāvokļa teksts bieži ir vērtīgāks par nemanāmu animāciju.

Automātiskās saglabāšanas pieprasījumi var pārklāties. Vecāka pieprasījuma vēlīna atbilde nedrīkst pārrakstīt saskarnē jaunāka darba statusu. Izstrādes pārbaudē mākslīgi aizkavējiet atbildes un pārbaudiet arī pretēju saņemšanas secību. Tā var atklāt kļūdu, kas ātrā biroja savienojumā nav redzama.

Pēc timeout nedrīkst automātiski pieņemt, ka saglabāšana nav notikusi. Serveris var būt izpildījis darbību, kaut gan pārlūks nav saņēmis atbildi. Vispirms jānoskaidro aktuālā versija un jāizvērtē saglabātais rezultāts. Atkārtota veca pieprasījuma akla nosūtīšana nav droša atkopšanas stratēģija.

Kā atgūt nesaglabātu tekstu

Lokālai darba kopijai jābūt sasaistītai ar konkrēto ierakstu, lietotāju un servera sākuma versiju. Atjaunojot darbu, saskarne var piedāvāt to salīdzināt, nevis uzreiz iesūtīt serverī. Jāparedz arī kopijas dzēšana un glabāšanas politika, īpaši koplietotās ierīcēs vai darbā ar sensitīvu informāciju.

Uz aiziešanas brīdinājumu vien paļauties nevar. MDN norāda, ka beforeunload notikums netiek uzticami izsaukts visās situācijās, piemēram, noteiktās mobilās lietošanas secībās. Pārlūka aiziešanas notikuma ierobežojumi. Darba saglabāšana jāprojektē visā rediģēšanas gaitā.

Pārbaudiet atkopšanu ar reāliem komandas darba apstākļiem: savienojuma zudumu, sesijas beigām un pārlūka atkārtotu atvēršanu. Paziņojums “Darbs atjaunots” nedrīkst nozīmēt tikai to, ka ielādēta veca servera kopija. Cilvēkam jāredz, kuras viņa izmaiņas ir atgūtas un kuras vēl nav saglabātas.

Ko prasīt CMS uzlabojuma pieņemšanā

Vienojieties par novērojamu rezultātu: novecojusi versija nevar klusi pārrakstīt jaunāku, konflikta paziņojums saglabā darbu un atkopšana nepārlec pāri aktualitātes pārbaudei. Pārbaudei jādarbojas arī pie aizkavētām atbildēm un integrācijas izmaiņām. Komandai nepieciešama īsa instrukcija, kā izvēlēties un apvienot redakcijas.

Vai ar versiju vēsturi pietiek?

Vēsture palīdz atjaunot jau pazaudētu saturu, ja attiecīgā versija ir saglabāta. Konflikta kontrole novērš klusu kļūdu saglabāšanas brīdī. Abiem mehānismiem ir atšķirīga loma, un vēsture neatceļ nepieciešamību cilvēkam skaidri paziņot par konfliktu.

Vai šī problēma prasa jaunu CMS?

Ne vienmēr. Vispirms jāizpēta esošais saglabāšanas ceļš, datu versijas un saskarnes iespējas. Iespējams, vajadzīgs lokāls uzlabojums. Ja sistēma neļauj vienādi aizsargāt visus rakstīšanas ceļus, jāvērtē plašākas izmaiņas ar konkrētu riska pamatojumu.

Ja komandā pazūd labojumi, sagatavojiet vienu atkārtojamu scenāriju un paredzamo rezultātu. Ar to var izvērtēt individuālas CMS izstrādes vai esošās sistēmas uzlabošanas apjomu. Satura lauku uzbūvi atsevišķi skaidro CMS satura modelis, bet programmatūras laidienus — staging vide un rollback plāns.