You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

69 lines
2.7 KiB

[FIX] privacy_consent: Separate automated emails send process 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()`.
6 years ago
  1. New options for data processing activities:
  2. #. Go to *Privacy > Master Data > Activities* and create one.
  3. #. Give it a name, such as *Sending mass mailings to customers*.
  4. #. Go to tab *Consent* and choose one option in *Ask subjects for consent*:
  5. * *Manual* tells the activity that you will want to create and send the
  6. consent requests manually, and only provides some helpers for you to
  7. be able to batch-generate them.
  8. * *Automatic* enables this module's full power: send all consent requests
  9. to selected partners automatically, every day and under your demand.
  10. #. When you do this, all the consent-related options appear. Configure them:
  11. * A smart button tells you how many consents have been generated, and lets you
  12. access them.
  13. * Choose one *Email template* to send to subjects. This email itself is what
  14. asks for consent, and it gets recorded, to serve as a proof that it was sent.
  15. The module provides a default template that should be good for most usage
  16. cases; and if you create one directly from that field, some good defaults
  17. are provided for your comfortability.
  18. * *Subjects filter* defines what partners will be elegible for inclusion in
  19. this data processing activity.
  20. * You can enable *Accepted by default* if you want to assume subjects
  21. accepted their data processing. You should possibly consult your
  22. lawyer to use this.
  23. * You can choose a *Server action* (developer mode only) that will
  24. be executed whenever a new non-draft consent request is created,
  25. or when its acceptance status changes.
  26. This module supplies a server action by default, called
  27. *Update partner's opt out*, that syncs the acceptance status with the
  28. partner's *Elegible for mass mailings* option.
  29. #. Click on *Generate consent requests* link to create new consent requests.
  30. * If you chose *Manual* mode, all missing consent request are created as
  31. drafts, and nothing else is done now.
  32. * If you chose *Automatic* mode, also those request e-mails are enqueued
  33. and, when the mail queue is cleared, they will be set as *Sent*.
  34. #. You will be presented with the list of just-created consent requests.
  35. See below.
  36. New options for consent requests:
  37. #. Access the consent requests by either:
  38. * Generating new consent requests from a data processing activity.
  39. * Pressing the *Consents* smart button in a data processing activity.
  40. * Going to *Privacy > Privacy > Consents*.
  41. #. A consent will include the partner, the activity, the acceptance status,
  42. and the request state.
  43. #. You can manually ask for consent by pressing the button labeled as
  44. *Ask for consent*.
  45. #. All consent requests and responses are recorded in the mail thread below.