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 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.
Jairo Llopis
Jairo Llopis
fkantelberg
Jairo Llopis