Open luckajirku opened 1 year ago
👍 - Můžeme k tomu dát "návrh na rozšíření"?
jj, tak to bylo myšleno, aby se s tím počítalo. i proto to sem dávám teď, i když je to takové hodně neurčité zatím...
Pak je otázka, jestli by to mělo kontrolovat už přímo při ukládání formuláře toho čísla/přílohy (bude fungovat jen když bude objekt ve struktuře, u samostatně založených by neměl proti čemu kontrolovat - ale těch bude minimum). Kde by to dávalo smysl vždycky, to by byla validace na úrovni ročníku, že by to směrem dolů pak zkontrolovalo, jestli roky sedí. Stejně tak u validace při exportu.
Týká se ručně zakládaných ročníků/čísel/příloh period a e-periodik, tj. ne objektů stahovaných z katalogu
jako úplný základ by tady měla být kontrola povolených hodnot na té které pozici (v závislosti na použitém formátu - https://github.com/proarc/proarc-client/issues/378) - př. MM může mít jen hodnotu 01-12 atp (teď můžu zadat klidně třináctý měsíc).
nebo jestli to půjde napojit na kalendář - a mít u dat obdobné kontroly jako při vytváření čísel periodika přes více...
Při uložení čísla kontrolovat, že rok dateIssue odpovídá roku vydání ročníku.
Kontrola pro NDK Číslo, NDK přílohu čísla, NDK přílohu ročníku.
@kerschfilip ověřit u NDK eDokumentů.
Odložím si tu issue s nejasným zadáním zatím k přemýšlení/diskusi. Bylo by fajn, kdyby šlo nějak víc hlídat u periodik datum. Kromě formátu jako takového (je v https://github.com/proarc/proarc-client/issues/378), kdyby PA upozornil na možnou chybu, pokud by číslo (příloha) pod ročníkem neodpovídalo tomu roku, který je v popisu ročníku. Stává se, že v čísle člověk zadá jiný rok (typicky ten současný, nebo na začátku dalšího ročníku dá automaticky rok z ročníku předchozího apod.)... Budou tam i zádrhele jako rozmezí let atd., ale hlídat by se to myslím dalo.