You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Najprv sa vytvori outbound Message instancia s processed rovnym NULL, s niekolkymi Recipient instanciami so status rovnym NULL.
Casom cron selectne unprocessed Message instancie, odosle ich ja vsetky Recipient adresy. Odoslana Message instancia sa oznaci ako odoslana a vsetkym jej Recipient instanciam sa nastavi status. Status sa nastavi v transport classe pri odosielani podla toho, cim sa odosiela. Vid SmtpTransport, MandrillTransport a DummyTransport.
Treba dorobit funkcionalitu, aby bolo mozne uz odoslany mail doposlat na dalsie adresy:
Pre Message instancie treba spravit metodu, ktora instancii vytvori novych recipientov so status NULL, a ak instancia uz bola processed, oznaci ju ako non-processed.
Tym padom cron takuto Message instanciu spracuje znovu. Treba vsak upravit vsetky implementacie transport class, aby tento email odoslal iba na nove adresy. Teda tie, ktore maju status NULL. Aktualne by sa email odoslal zvnovu aj na adresy, ktore tam boli uz predtym.
Pls, poriadne skontroluj celu codebase, ci zmena processed existujucej Message instancie na NULL nieco niekde v codebase nerozbije.
2. Doposielanie mailov akcii na nove obligee adresy
Do admin detailu Action instancie treba dorobit button, na doposlanie mailu na nove adresy institucie. Napriklad ak od casu odoslania akcie institucii pribudla v DB nova adresa institucie, akciu treba doposlat aj na tuto novu adresu.
Button sa zobrazi iba ak:
ide o applicant action odoslanu emailom
delivered_date akcie je NULL (ten by mal byt pre applicant akcie vzdy NULL)
ide o poslednu action v branchi, alebo po nej je uz iba niektora z expiration akcii
v aktualnej verzii action.branch.obligee.emails existuje mailova adresa, na ktoru action.email nebol odoslany
Button by som dal bud do riadku ku fieldu "Email" alebo k buttonom "History" a "View on site" v pravom hornom rohu. Urcite by som ho nedaval k buttonom "Save" a podobne.
Button bude fungovat dvojkrokovo, podobne ako mazanie instancii. Ked admin klikne na button, zobrazi sa potvrdzujuca obrazovka, na ktorej sa vypise sumar, co sa ide spravit vratane zoznamu emailov, na ktore sa akcia doposle.
Ak admin doposlanie akcie potvrdi, action.email sa doposle na nove adresy z action.branch.obligee.emails. Doposlanie mailu sa vykona zavolanim metody z prveho bodu vyssie.
Po odoslani akcie na nove adresy sa instancia akcie upravi nasledovne:
created a delivered_date ostanu nezmenene
sent_date a legal_date sa zmenia na aktualny datum
snooze a last_deadline_reminder sa resetnu na NULL
ak akcia nie je poslednou v branchi, ale ma po sebe niektoru z expiration akcii, expiration akcia sa zmaze
ak infoziadost ku ktorej akcia patri je closed, tak sa infoziadost naspat otvori
Pls, poriadne skontroluj celu codebase, ci zmeny v akcii, zmazanie expiration akcie, alebo znovuotvorenie closed infoziadosti nieco niekde v codebase nerozbije.
3. Doposielanie mailov akcii na rucne zadane adresy
Upravit button z predosleho bodu, aby sa zobrazoval aj ked v action.branch.obligee.emails nie je ziadna nova adresa. A na potvrdzujucu obrazovku pridat widget na rucne zadania adries, kam sa ma email doposlat. Ak admin zada nejake adresy rucne, email sa doposle aj na ne. Ak admin nezada ziadne nove adresy, a ani v action.branch.obligee.emails nie su ziadne nove adresy, doposlanie mailu nepojde potvrdit.
The text was updated successfully, but these errors were encountered:
Co s datumami ako "Created", "Sent", "Delivered", "Legal date" a "Snooze" pri akcii, ked sa doposle na nove adresy. Prepocitat ich alebo nechat povodne?
Navhrujem:
Created: nechat
nastavit Sent = Legal date= now() , cize nastavil by som, ze sa realne aj legalne odoslala ziadost az teraz. Totiz, casto adresa institucie je expirovana a v skutocnosti maju na svojej stranke uvedenu inu adresu na prijimanie infoziadosti, takze nedoslo ku korektnemu poziadaniu. Snooze by som nechal na nule.
Ak bol medzicasom podnet uzavrety, otvorit ho
Ak medzicasom vznikla akcia "vyprsala lehota", zmazat ju.
@mmmaly Zmeny datumov som zapracoval do zadania. Zmenil som to tak, ze nepojde doposielat maily z detailu mailu, ale iba z detailu akcie. Pretoze z datailu mailu sa nedaju upravit vlastnosti akcie, ku ktorej mail patri.
Aktualne posielanie emailov funguje takto:
Message
instancia sprocessed
rovnym NULL, s niekolkymiRecipient
instanciami sostatus
rovnym NULL.Message
instancie, odosle ich ja vsetkyRecipient
adresy. OdoslanaMessage
instancia sa oznaci ako odoslana a vsetkym jejRecipient
instanciam sa nastavistatus
. Status sa nastavi v transport classe pri odosielani podla toho, cim sa odosiela. VidSmtpTransport
,MandrillTransport
aDummyTransport
.Treba dorobit funkcionalitu, aby bolo mozne uz odoslany mail doposlat na dalsie adresy:
Message
instancie treba spravit metodu, ktora instancii vytvori novych recipientov sostatus
NULL, a ak instancia uz bola processed, oznaci ju ako non-processed.Message
instanciu spracuje znovu. Treba vsak upravit vsetky implementacie transport class, aby tento email odoslal iba na nove adresy. Teda tie, ktore majustatus
NULL. Aktualne by sa email odoslal zvnovu aj na adresy, ktore tam boli uz predtym.Pls, poriadne skontroluj celu codebase, ci zmena
processed
existujucejMessage
instancie na NULL nieco niekde v codebase nerozbije.Do admin detailu
Action
instancie treba dorobit button, na doposlanie mailu na nove adresy institucie. Napriklad ak od casu odoslania akcie institucii pribudla v DB nova adresa institucie, akciu treba doposlat aj na tuto novu adresu.Button sa zobrazi iba ak:
delivered_date
akcie je NULL (ten by mal byt pre applicant akcie vzdy NULL)action.branch.obligee.emails
existuje mailova adresa, na ktoruaction.email
nebol odoslanyButton by som dal bud do riadku ku fieldu "Email" alebo k buttonom "History" a "View on site" v pravom hornom rohu. Urcite by som ho nedaval k buttonom "Save" a podobne.
Button bude fungovat dvojkrokovo, podobne ako mazanie instancii. Ked admin klikne na button, zobrazi sa potvrdzujuca obrazovka, na ktorej sa vypise sumar, co sa ide spravit vratane zoznamu emailov, na ktore sa akcia doposle.
Ak admin doposlanie akcie potvrdi,
action.email
sa doposle na nove adresy zaction.branch.obligee.emails
. Doposlanie mailu sa vykona zavolanim metody z prveho bodu vyssie.Po odoslani akcie na nove adresy sa instancia akcie upravi nasledovne:
created
adelivered_date
ostanu nezmenenesent_date
alegal_date
sa zmenia na aktualny datumsnooze
alast_deadline_reminder
sa resetnu na NULLclosed
, tak sa infoziadost naspat otvoriPls, poriadne skontroluj celu codebase, ci zmeny v akcii, zmazanie expiration akcie, alebo znovuotvorenie closed infoziadosti nieco niekde v codebase nerozbije.
Upravit button z predosleho bodu, aby sa zobrazoval aj ked v
action.branch.obligee.emails
nie je ziadna nova adresa. A na potvrdzujucu obrazovku pridat widget na rucne zadania adries, kam sa ma email doposlat. Ak admin zada nejake adresy rucne, email sa doposle aj na ne. Ak admin nezada ziadne nove adresy, a ani vaction.branch.obligee.emails
nie su ziadne nove adresy, doposlanie mailu nepojde potvrdit.The text was updated successfully, but these errors were encountered: