Refactorovat mazanie instancii

[martinmacko47]

Logiku mazania instancii v admin rozhrani sme mali rozhadzanu po vela taskoch, v ktorych mame chos. Spojil som ich tu do jedneho tasku, nech v tom mame poriadok a lepsie sa trackuje, co uz je spravene a co nie. Taktiez teraz, ked mame {% amend %} template tag, zrejme kopec veci pojde spravit elegantnejsie.

Jednotlive veci rob postupne v samostatnych PR. Kludne aj viac PR na jeden checkbox. Checkbox sa zaskrtne, ked bude dany bod hotovy cely.

Najprv zober niektory vzorovy model a vyskusaj na nom, ako vieme mazanie implementovat. Potom to rovnakym sposobom implementujeme pre zvysne modely:

• Ci warningy a ine informacie zobrazene pred samotnym mazanim vieme pomocou {% amend %} template tagu alebo inou upravou templatu presunut von zo zoznamu rekurzivne mazanych instancii, do separatneho odstavca. Nech zbytocne nezneuzivame context[u'deleted_objects'] na ine veci. Vid obrazok:
  
  Ak ano:
  • Presun do separatneho odstavca vsetky warningy, co sa pri deletovani zobrazuju
  • Presun do separatneho zoznamu "Outbound messages will be deleted" a "Inbound messages will be marked undecided" zoznamy
  • Pozri kde inde este zneuzivame context[u'deleted_objects'] na nieco ine, nez je urcene a tiez to presun do samostatnych odstavcov.
• Ci pomocou {% amend %} template tagu alebo inou upravou templatu vieme nejak elegantne spravit mazanie jednej instancie tak, ze ak sa instancia z nejakeho dovodu nema dat zmazat, tak na obrazovke, kde sa mazanie potvrzuje, sa zobrazi dovod, preco sa instancia zmazat neda, a button na potvrdenie zmazania tam nezobrazit.
• Ci pomocou {% amend %} template tagu uz vieme nejak elegantne spravit hromadne mazanie oznacenych instancii, s tym, ze ak niektoru z oznacenych instancii z nejakeho dovodu nebude mozne zmazat, tak na obrazovke, kde sa mazanie potvrzuje, sa zobrazi dovod, preco sa instancia zmazat neda, a button na potvrdenie zmazania tam nezobrazit. Ak sa to teraz uz da, tak vsetkym modelom hromadne mazanie povolime. Inac vsetkym modelom hromadne mazanie zakazeme.

Podmienky pre jednotlive modely, kedy sa maju dat zmazat:

• Action: Ostavaju rovnake, ako uz mame iplementovane, len samotne mazanie treba prerobit ako je popisane vyssie:
  • Nie je mozne zmazat REQUEST ani ADVANCED_REQUEST
  • Nie je mozne zmazat akciu, ktora je jedina v branchi.
  • Ak mazana akcia nie je posledna v branchi, zobrazi sa warning
  • Ak mazana akcia je EXPIRATION alebo APPEAL_EXPIRATION, tak sa zobrazi checkbox sa predlzenie snooze predoslej akcie
  • Zobrazi sa zoznam suvisiacich InforequestEmail instancii, ktore sa zmazu resp. oznacia za undecided
• Branch: Ostavaju rovnake, ako uz mame iplementovane, len samotne mazanie treba prerobit ako je popisane vyssie:
  • Nie je mozne zmazat main branch
  • Zobrazi sa zoznam suvisiacich InforequestEmail instancii, ktore sa zmazu resp. oznacia za undecided
• InforequestEmail:
  • Nie je mozne zmazat InforequestEmail odkazujuci na email Message, ktory je pouzity v niektorej Action prislusnej ziadosti. Teda, ze vzdy musi byt splneny invariant, ze vsetky Message pouzite v akciach infoziadosti, musia byt nalinkovane na infoziadost aj cez InforequestEmail.
• Inforequest:
  • Povolene je mazanie vsetkych ziadosti, kedze ziadne infoziadosti nie su nicim specialne tak, aby ich nebolo mozne zmazat. Proces mazania zrejme upravovat netreba, kedze s infoziadostou by sa malo automaticky zmazat vsetko, co s nou suvisi. Len treba overit, ze to funguje. Mimo infoziadosti zrejme tiez netreba nic upravovat.
  • Ked sa zmaze Inforequest, tak sa zmazu vsetky veci, co s nim suvisia, ale samotne maily, teda instancie Message, ktore pre tuto ziadost vznikli, sa nezmazu. Zmena sa iba ich priradenie ziadosti cez InforequestEmail.
• InforequestDraft:
  • Povolene je mazanie vsetkych draftov ziadosti.
• WizardDraft
  • Povolene je mazanie vsetkych draftov wizadru
• Message / Recipient / Attachment:
  • Nie je mozne zmazat Message ani Attachment, na ktory je od niekial FK, okrem z Attachment a Recepient. Ak bude admin chciet zmazat Message alebo Attachment, bude musiet najprv porusit FK nan. Aby zmazanim Message resp. Attachment sa nezmazalo nieco, co nechceme.
  • Ked sa zmaze Message tak sa s nim automaticky zmazu vsetky jeho Attachment a Recepient.
  • Model Recepient nema vlastny admin, je iba ako inline v ramci Message. Takze jeho mazanie funguje inac.
  • Implementacia by sa nemala spoliehat na kod z "chcemvediet" apps, kedze app "mails" a "attachments" su univerzalne. Treba pouzit Django mechanizmus na zistenie, co by sa s danym Message slo zmazat, a povolit to zmazat, iba ak tam nie je nic okrem Attachment a Recepient. Pripadne skusit, ci to nejde spravit nejak automaticky pomocou ForeignKey.on_delete.
• ObligeeTag / ObligeeGroup / Obligee / HistoricalObligee / ObligeeAlias:
  • Uplne zakazat mazanie. Kedze databaza institucii sa importuje z externeho suboru, nemalo by byt povolene ju editovat rucne. Lebo pri dalsom importe sa zmeny stratia.
• Region / District / Municipality / Neighbourhood:
  • Uplne zakazat mazanie. Kedze databaza geounits sa importuje z externeho suboru, nemalo by byt povolene ju editovat rucne. Lebo pri dalsom importe sa zmeny stratia.
• Profile / InvitationSupply
  • Uplne zakazat mazanie. Kedze pre kazdeho usera ma vzdy existovat prave jedna instancia Profile a jedna instancia InvitationSupply, tak sa nesmu mazat samostatne. Zmazu sa iba, ked sa zmaze cely user.
• Invitation
  • Povolene je mazanie vsetkych invitations. Zmazanie pouzitej invitation by nemalo mat ziaden vplyv na usera, ktory bol nou invitnuty.
• AttachmentNormalization / AttachmentRecognition / AttachmentAnonymization / AttachmentFinalization:
  • Povolene je mazanie vsetkych uprav priloh.
  • Ak sa zmaze AttachmentNormalization, tak sa automaticky zmaze aj AttachmentRecognition a ostatne pre ten isty attachment
  • Ak sa zmaze AttachmentRecognition, tak sa automaticky zmaze aj AttachmentAnonymization a AttachmentFinalization pre ten isty attachment
  • Ak sa zmaze AttachmentAnonymization, tak sa automaticky zmaze aj AttachmentFinalization

Mazanie modelov z externych kniznic. Najprv treba zistit, ci vobec vieme nejako upravid admin pre modely z externych kniznit. A ak ano, tak potom:

• Sites: Mazanie je zakazane. Instancie sa vytvaraju vo fixtures
• Social Accounts:
  • Social accounts: Mazat sa mozu vsetky instancie
  • Social application tokens: Mazat sa mozu vsetky instancie
  • Social applications: Mazanie je zakazane. Instancie sa vytvaraju vo fixtures
• Authentication and Authorization:
  • Groups: Mazat sa mozu vsetky instancie
  • Users: Mazat sa mozu vsetky instancie. S userom sa zmazu vsetky jeho veci v DB.
• Accounts
  • Email addresses: Nie je mozne zmazat userov primary email. Ostatne emaily sa mazat mozu.
  • Email confirmations: Mazat sa mozu vsetky instancie

Nakoniec:

• Pozriet, ake nove modely sme do projektu medzicasom pridali a zamysliet sa, ci a za akych podmienok ich instancie moze admin mazat.