- Remove prefetching optimizations; v13 ORM does it better.
- Reset counters always in computed methods.
- Remove workaround for skipping duplicate consent creation message.
- Implement the new `_creation_subtype()` to let creation subscriptions keep on working.
@Tecnativa TT25941
Some little nasty details were overlooked in the v12 migration, which rendered the module basically useless:
- The wizard used to ask for consent in manual activities did not fill the placeholders, resulting in an awkward UX.
- The sent mails **did not have the token** to authenticate and actually allow accepting or rejecting. These buttons returned a 500 error.
- Once the token is added, the form was ugly.
- Sadly, some tests were testing the how and not the what. It is understandable due to the complexity of testing the what, even more without the `Form` utility, new on v12. These are fixed now too.
@Tecnativa TT25868
Due to a bug present in the `_postprocess_sent_message` code, if a consent wasn't successfully sent, still the consent got marked as sent.
It should stay as draft. Modify tests to test this new behavior.
@Tecnativa TT24457
- Partner's `opt_out` no longer exists. Using `mail.blacklist` now.
- Tests updated to support that change.
- Test workarounds removed.
- Duplicated-field-name-in-model warning removed.
- Use create multi where possible.
Before https://github.com/OCA/data-protection/pull/29 there was a race condition where an email could be sent while the same transaction that created the `privacy.consent` record still wasn't committed, producing a 404 error if the user clicked on "Accept" or "Reject" before all mails were sent.
To avoid that, a raw `cr.commit()` was issued, but this produced another situation where the user had to wait until the full email queue is cleared to get his page loaded. It wasn't an error, but a long queue meant several minutes waiting, and it's ulikely that an average human is so patient.
So, here's the final fix (I hope!). The main problem was that I was looking in the wrong place to send the email. It turns out that the `self.post_message_with_template()` method is absolutely helpless in the case at hand, where these criteria must be met:
* E-mail must be enqueued, no matter if there are less or more than 50 consents to send.
* The template must be processed per record.
* In an ideal world, a `cr.commit()` must be issued after each sent mail.
The metod that was being used:
* Didn't allow to use `auto_commit` mode.
* Only allowed to render the template per record if called with `composition_mode="mass_mail"`.
* Only allowed to enqueue emails if called with `composition_mode="mass_post"`.
Obviously, I cannot set 2 different values for `composition_mode`, so a different strategy had to be used.
I discovered that the `mail.template` model has a helpful method called `send_mail()` that, by default:
* Renders the template per record
* Enqueues the email
* The email queue is cleared in `auto_commit=True` mode.
So, from now on, problems are gone:
* The user click, or the cron run, will just generate the missing `privacy.consent` records and enqueue mails for them.
* The mail queue manager will send them later, in `auto_commit` mode.
* After sending the e-mail, this module will set the `privacy.consent` record as `sent`.
* Thanks to *not* sending the email, the process the user faces when he hits the "generate" button is faster.
* Instructions in the README and text in the "generate" button are updated to reflect this new behavior.
* Thanks to the `auto_commit` feature, if Odoo is rebooted in the middle of a mail queue clearance, the records that were sent remain properly marked as sent, and the missing mails will be sent after the next boot.
* No hardcoded commits.
* No locked transactions.
* BTW I discovered that 2 different emails were created when creating a new consent. I started using `mail_create_nolog=True` to avoid that problem and only log a single creation message.
Note to self: never use again `post_message_with_template()`.
It could happen that, while Odoo is still sending emails, a subject receives it and clicks on accept/reject links.
In such case, he'd get a 404 error because the record wouldn't exist yet in the database. That's because the DB commit was made only after processing all the sent emails.
We need to commit in advance to make sure that doesn't happen.
Before this patch, all privacy consent emails were forced to be sent under a context with `mark_consent_sent=True` to track the state change and trigger the attached server action.
When using the automatic mode, if a separate cron job started running the mail queue, it could happen that mails were being sent from that another worker, losing the context key and, as such, being sent without token and without being marked as sent nor executing the attached server action (if any).
To avoid this problem, now the context dependency is removed. After all, the `mail.mail` object is only created when sending in `mass_mail` model, so other kind of notifications or messages are not affected. When a mail of type `mass_mail` is sent, we can assume that it is asking for consent and we can move draft consent requests to sent.
sergiocorato
Jairo Llopis
Jairo Llopis
Jairo Llopis
fkantelberg