Command na nahratie `AttachmentFinalization`

[martinmacko47]

V app anonymization treba spravit management command attachment_anonymization na vytvorenie AttachmentFinalization pre dany attachment. Pozri management adresare v ostatnych apps, ako sa robia management command robia.

Experimentujeme s externymi anonymizacnymi skriptami. Aby tie skripty nemuseli zasahovat priamo do DB, ani hackovat admin rozhranie, spravime commandline tool, ktorym sa da do DB nahrat AttachmentFinalization rucne resp. skriptom.

Command bude mat parametre:

manage.py attachment_anonymization attachment [options] [file]

Kde:

• attachment: ID attachmentu. Musi byt uvedene. Musi to byt attachment priradeny nejakej Action, rovnako ako je podmieka v normalize_attachment.
• file: Cesta k suboru, ktory sa nahraje ako AttachmentFinalization. Ak nie je uvedene, subor sa nacita zo stdin. Ak na stdin nie je nic, command failne.

Options su:

• --content-type: Content type ukladaneho suboru. Ak nie je uvedene, content type sa tipne z obsahu suboru.
• --debug: Lubovolny string, co sa ulozi do debug fieldu. Ak nie je uvedene, ulozi sa prazdny string.
• --force: Ak v DB uz existuje "successful" AttachmentFinalization pre dany attachment, tak command failne ak nie je uvedeny parameter --force. Ak parameter uvedeny je, tak existujuce instancie sa zmazu a vytvori sa nova.

Vsetky takto vytvorene instancie AttachmentFinalization budu "successful". Taktiez command bude mat zatial obmedzenie, ze pre jeden attachment bude moct byt v DB iba jeden AttachmentFinalization. V buducnosti to mozno zovseobecnime.

Vytvorenemu commandu napis zrozumitelnu --help dokumentaciu. A tiez ho zdokumentuj do misc/anonymization.md. Btw, hoc realne vytvarame instanciu AttachmentFinalization, v dokumentacii commandu vsade pis o anonymizacii, nie o finalizacii. Kedze z pohladu externych skriptov je to cele anonymizacia. Slovo finalizacia je iba nasa technikalita v ramci anonymizacnej app.

[martinmacko47]

@mmmaly Tool na nahravanie anonymizacii priloh je hotovy a mergnuty. Pls otestuj:

env/bin/python manage.py attachment_anonymization attachment_id file

alebo:

foo.sh | env/bin/python manage.py attachment_anonymization attachment_id

Pre viac info:

env/bin/python manage.py attachment_anonymization --help

[mmmaly]

Skusam, zda sa, ze to funguje. Poznamky (viac menej pre seba):

• pre ODT dokument treba uviest --content_type "application/vnd.oasis.opendocument.text", inak sa rozpozna ako ZIP
• pri uvedeni ODT dokumentu nedochadza k ziadnej dalsej konverzii, je zverejneny ako ODT (bez konverzie na PDF)
• attachment_id je id z tabulky attachments_attachment (attachments_attachment.id), resp. stlpec attachment_id z pomocnych tabuliek (napr. anonymization_attachmentrecognition.attachment_id)
• --force funguje prakticky okamzite (stary link na attachment sa znehodnoti, treba refresh)

[mmmaly]

Pouzivam to so subormi vytvorenymi skriptom https://github.com/Chcemvediet-sk/anonymization

poznamka: Este nezatvarat, este treba:

• dokumentaciu, vid hore
• interfacovanie na databazu (aktualne to vytahujem osobitne)
• dohodnut nahradenie terajsieho skriptu
• specialne pripady

[martinmacko47]

@mmmaly

pri uvedeni ODT dokumentu nedochadza k ziadnej dalsej konverzii, je zverejneny ako ODT (bez konverzie na PDF)

Ano, tento tool sluzi na nahranie finalnej podoby zverejneneho suboru. Teda zvycajne PDF. Ak vsak niekedy budeme potrebovat zverejnit iny typ suboru, mozeme ho sem nahrat. Ziadna konverzia na PDF sa po nahrati suboru uz nerobi.

pre ODT dokument treba uviest --content_type "application/vnd.oasis.opendocument.text", inak sa rozpozna ako ZIP

To bude bug. Tool by si mal content type suboru tipnut spravne. Bud mas vadny ODT subor, alebo my mame vadny checker. Pls sprav pre to bugreport aj so vzorovym suborom, ktory to rozpozna zle. Ak ten subor nechces zverejnit vo verejnej issue, tak plsl sprav nejaky testovaci ODT subor, co sa rovnako sprava. Alebo mi ho posli mailom.

Do bugreportu pls popis aj ako ten ODT subor vznikol. Ci si ho vyrobil nejak rucne, alebo z akeho SW je to savnute.

poznamka: Este nezatvarat, este treba:

Tento "task" issue je iba o commande na nahravanie anonymizovanej verzie. Pre ostatne veci som spravil separatnu "epic" issue #373, v ktorej budeme postupne trackovat "task" issues na jednotlive dielcie veci.

Ak samotny command na nahravanie anonymizovanej verzie funguje dostatocne. Tak tento task zavrieme. Pre pripadne bugy mozeme vytvorit separatne "bug" issues.