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.

173 lines
6.3 KiB

6 years ago
6 years ago
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
6 years ago
  1. =================
  2. Privacy - Consent
  3. =================
  4. .. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  5. !! This file is generated by oca-gen-addon-readme !!
  6. !! changes will be overwritten. !!
  7. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  8. .. |badge1| image:: https://img.shields.io/badge/maturity-Production%2FStable-green.png
  9. :target: https://odoo-community.org/page/development-status
  10. :alt: Production/Stable
  11. .. |badge2| image:: https://img.shields.io/badge/licence-AGPL--3-blue.png
  12. :target: http://www.gnu.org/licenses/agpl-3.0-standalone.html
  13. :alt: License: AGPL-3
  14. .. |badge3| image:: https://img.shields.io/badge/github-OCA%2Fdata--protection-lightgray.png?logo=github
  15. :target: https://github.com/OCA/data-protection/tree/10.0/privacy_consent
  16. :alt: OCA/data-protection
  17. .. |badge4| image:: https://img.shields.io/badge/weblate-Translate%20me-F47D42.png
  18. :target: https://translation.odoo-community.org/projects/data-protection-10-0/data-protection-10-0-privacy_consent
  19. :alt: Translate me on Weblate
  20. .. |badge5| image:: https://img.shields.io/badge/runbot-Try%20me-875A7B.png
  21. :target: https://runbot.odoo-community.org/runbot/263/10.0
  22. :alt: Try me on Runbot
  23. |badge1| |badge2| |badge3| |badge4| |badge5|
  24. This module allows the user to define a set of subjects (partners)
  25. affected by any data processing activity, and establish
  26. a process to ask them for consent to include them in that activity.
  27. For those that need explicit consent as a lawfulness base for personal data
  28. processing, as required by GDPR (article 6.1.a), this module provides the
  29. needed tools to automate it.
  30. **Table of contents**
  31. .. contents::
  32. :local:
  33. Installation
  34. ============
  35. You may want to install, along with this module, one of OCA's
  36. ``mail_tracking`` module collection, such as ``mail_tracking_mailgun``, so
  37. you can provide more undeniable proof that some consent request was sent, and
  38. to whom.
  39. However, the most important proof to provide is the answer itself (more than
  40. the question), and this addon provides enough tooling for that.
  41. Multi-database instances
  42. ~~~~~~~~~~~~~~~~~~~~~~~~
  43. To enable multi-database support, you must load this addon as a server-wide
  44. addon. Example command to boot Odoo::
  45. odoo-bin --load=web,privacy_consent
  46. Usage
  47. =====
  48. New options for data processing activities:
  49. #. Go to *Privacy > Master Data > Activities* and create one.
  50. #. Give it a name, such as *Sending mass mailings to customers*.
  51. #. Go to tab *Consent* and choose one option in *Ask subjects for consent*:
  52. * *Manual* tells the activity that you will want to create and send the
  53. consent requests manually, and only provides some helpers for you to
  54. be able to batch-generate them.
  55. * *Automatic* enables this module's full power: send all consent requests
  56. to selected partners automatically, every day and under your demand.
  57. #. When you do this, all the consent-related options appear. Configure them:
  58. * A smart button tells you how many consents have been generated, and lets you
  59. access them.
  60. * Choose one *Email template* to send to subjects. This email itself is what
  61. asks for consent, and it gets recorded, to serve as a proof that it was sent.
  62. The module provides a default template that should be good for most usage
  63. cases; and if you create one directly from that field, some good defaults
  64. are provided for your comfortability.
  65. * *Subjects filter* defines what partners will be elegible for inclusion in
  66. this data processing activity.
  67. * You can enable *Accepted by default* if you want to assume subjects
  68. accepted their data processing. You should possibly consult your
  69. lawyer to use this.
  70. * You can choose a *Server action* (developer mode only) that will
  71. be executed whenever a new non-draft consent request is created,
  72. or when its acceptance status changes.
  73. This module supplies a server action by default, called
  74. *Update partner's opt out*, that syncs the acceptance status with the
  75. partner's *Elegible for mass mailings* option.
  76. #. Click on *Generate consent requests* link to create new consent requests.
  77. * If you chose *Manual* mode, all missing consent request are created as
  78. drafts, and nothing else is done now.
  79. * If you chose *Automatic* mode, also those request e-mails are enqueued
  80. and, when the mail queue is cleared, they will be set as *Sent*.
  81. #. You will be presented with the list of just-created consent requests.
  82. See below.
  83. New options for consent requests:
  84. #. Access the consent requests by either:
  85. * Generating new consent requests from a data processing activity.
  86. * Pressing the *Consents* smart button in a data processing activity.
  87. * Going to *Privacy > Privacy > Consents*.
  88. #. A consent will include the partner, the activity, the acceptance status,
  89. and the request state.
  90. #. You can manually ask for consent by pressing the button labeled as
  91. *Ask for consent*.
  92. #. All consent requests and responses are recorded in the mail thread below.
  93. Bug Tracker
  94. ===========
  95. Bugs are tracked on `GitHub Issues <https://github.com/OCA/data-protection/issues>`_.
  96. In case of trouble, please check there if your issue has already been reported.
  97. If you spotted it first, help us smashing it by providing a detailed and welcomed
  98. `feedback <https://github.com/OCA/data-protection/issues/new?body=module:%20privacy_consent%0Aversion:%2010.0%0A%0A**Steps%20to%20reproduce**%0A-%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**>`_.
  99. Do not contact contributors directly about support or help with technical issues.
  100. Credits
  101. =======
  102. Authors
  103. ~~~~~~~
  104. * Tecnativa
  105. Contributors
  106. ~~~~~~~~~~~~
  107. * `Tecnativa <https://www.tecnativa.com>`_:
  108. * Jairo Llopis
  109. Maintainers
  110. ~~~~~~~~~~~
  111. This module is maintained by the OCA.
  112. .. image:: https://odoo-community.org/logo.png
  113. :alt: Odoo Community Association
  114. :target: https://odoo-community.org
  115. OCA, or the Odoo Community Association, is a nonprofit organization whose
  116. mission is to support the collaborative development of Odoo features and
  117. promote its widespread use.
  118. This module is part of the `OCA/data-protection <https://github.com/OCA/data-protection/tree/10.0/privacy_consent>`_ project on GitHub.
  119. You are welcome to contribute. To learn how please visit https://odoo-community.org/page/Contribute.