Požadavek #16
otevřenýInterní dokumenty
Přidáno uživatelem Michal Kliment před více než 12 roky(ů). Aktualizováno před více než 4 roky(ů).
0%
Popis
Možnost využít freenetis jako úložiště elektronických interních dokumentů.
Navíc možnost takové dokumenty generovat přímo ve freenetisu - v současnosti umí pouze export přihlášky, v budoucnu by měl umět export odhlášky, dohodu o DPP, smlouvu o zápujčce, atd.
Dílčí úkoly 1 (1 otevřený — 0 uzavřených)
Související úkoly 1 (1 otevřený — 0 uzavřených)
Aktualizováno uživatelem Ondřej Fibich před téměř 12 roky(ů)
- Cílová verze změněn z 1.0 na 1.1
Aktualizováno uživatelem Ondřej Fibich před více než 11 roky(ů)
- Odhadovaná doba nastaven na 25:00hod
Aktualizováno uživatelem Ondřej Fibich před asi 11 roky(ů)
- Odhadovaná doba změněn z 25:00hod na 40:00hod
Návrh¶
Každý dokument by měl mít přiřazeny skupiny typů uživatelů (M:N), kteří je mohou a) shlížet b) editovat.
Dále by měla existovat možnost stromové struktury kategorií dokumentů, opět s možností stanovení práv pro a) čtení a b) editaci (=re-upload) a přidávání souborů (včetně jejich práv). Možnost přidávat kategorii bych ponechal pouze na administrátorovi (tj. staticky v gaclu).
Při změně souboru by bylo vhodné informovat vnitřní poštou lidi, kteří mají pro dané dokumenty čtecí práva (nebo jinak, což by se volilo právě při editaci editorem).
Dále by bylo dobré navázat komentáře k jednotlivým dokumentům (půl hodina práce).
Příklady případů užití¶
- Běžný člen by měl dostupné třeba: dokumenty se stanovami o.s., zápisy z VH, ...
- Ostatní by mohli sdílet nějaké interní dokumenty
Implementace¶
Jedná se tedy o 4 DB tabulky files(id, category_id, name, type, data, ...), file_categories(id, name, ...), files_permissions(file_id, aro_group_id), file_categories_permisions(file_category_id, aro_group_id).
- files.data je typu LONGBLOB, muselo by se zajistit, aby se nenačítal v žádném dotazu, krom downloadu dokumentu. (mělo by nějak jít pomocí ORM). Důvod: mohlo by to způsobit obrovské výkonnostní problémy na serveru.
- soubory mohou zabírat hodně místa, ale pokud je dost místa na disku a implementuje se to tak jak je uvedeno výše, mělo by to být OK
Možné vylepšení¶
- možnost náhledu v GDocs/M$ Office Live (nevím jestli by to vůbec šlo :-))
P.S. Čekám vaše připomínky ;-)
Aktualizováno uživatelem Michal Kliment před asi 11 roky(ů)
Bylo by dobré, kdyby tyto dokumenty měly podporu proměnných (např. {member_id}, {balance}, apod). Při použití na určitém členovi by se samy doplnily, jinak by se místo nich doplnily prázdné čáry. Člen by si pak mohl stáhnout vlastní přihlášku, převod členství, atd. Podle mě je to nutná vlastnost.
Ještě by se u dokumentů mohl kromě těch náhledů udělat exporty do doc/HTML/PDF, takže by se zároveň vyřešilo i #407.
Aktualizováno uživatelem Michal Kliment před asi 11 roky(ů)
- Cílová verze změněn z 1.1 na 1.2
Aktualizováno uživatelem Michal Kliment před více než 10 roky(ů)
- Přiřazeno nastaven na Michal Kliment
Aktualizováno uživatelem Ondřej Fibich před asi 10 roky(ů)
- Kategorie nastaven na Doplňkové služby
Aktualizováno uživatelem Michal Kliment před více než 9 roky(ů)
- Přiřazeno změněn z Michal Kliment na Jan Dubina
Aktualizováno uživatelem Filip Miškařík před více než 4 roky(ů)
- Přiřazeno změněn z Jan Dubina na Filip Miškařík
Po zkušenostech z vytížení databáze z freenetisu pro UnArtel při nahrávání souborů ve formátu LONGBLOB přímo do databáze navrhuji, aby se soubory ukládaly na server a do databáze ukládat pouze cestu k tomuto souboru.
Aktualizováno uživatelem Ondřej Fibich před více než 4 roky(ů)
Filip Miškařík napsal:
Po zkušenostech z vytížení databáze z freenetisu pro UnArtel při nahrávání souborů ve formátu LONGBLOB přímo do databáze navrhuji, aby se soubory ukládaly na server a do databáze ukládat pouze cestu k tomuto souboru.
V čem nastal prosím problém? Raději bych měl vše v DB, je to jednodušší na správu a méně náchylné na lidské chyby.
Aktualizováno uživatelem Michal Kliment před více než 4 roky(ů)
Ondřej Fibich napsal:
V čem nastal prosím problém? Raději bych měl vše v DB, je to jednodušší na správu a méně náchylné na lidské chyby.
Kromě výkonnostních problémů s databází (ta měla asi 3 GB) byl problém i se zálohováním - jeden zazipovaný dump DB měl kolem 2GB. Kdežto zálohování souborů lze provést i pouze inkrementálně (tj ukládat pouze změny).
Aktualizováno uživatelem Ondřej Fibich před více než 4 roky(ů)
- Cesty byly pouze relativní vůči root adresáři. Root by byl nastaven v config.php, defaultně např.
/var/lib/freenetis/dms
. Díky relativním cestám lze snadno migrovat. - Soubory nebyly stahovány přímo jako statické, ale bylo zohledněno dříve navržených přístupových práv.
Aktualizováno uživatelem Filip Miškařík před více než 4 roky(ů)
- Stav změněn z Nový na Odeslaný