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.

234 lines
10 KiB

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
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
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
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
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. # Copyright 2018 Tecnativa - Jairo Llopis
  2. # License AGPL-3.0 or later (http://www.gnu.org/licenses/agpl).
  3. from odoo.exceptions import ValidationError
  4. from odoo.tests.common import HttpCase
  5. class ActivityCase(HttpCase):
  6. def setUp(self):
  7. super(ActivityCase, self).setUp()
  8. self.cron = self.env.ref("privacy_consent.cron_auto_consent")
  9. self.cron_mail_queue = self.env.ref(
  10. "mail.ir_cron_mail_scheduler_action")
  11. self.sync_blacklist = self.env.ref("privacy_consent.sync_blacklist")
  12. self.mt_consent_consent_new = self.env.ref(
  13. "privacy_consent.mt_consent_consent_new")
  14. self.mt_consent_acceptance_changed = self.env.ref(
  15. "privacy_consent.mt_consent_acceptance_changed")
  16. self.mt_consent_state_changed = self.env.ref(
  17. "privacy_consent.mt_consent_state_changed")
  18. # Some partners to ask for consent
  19. self.partners = self.env["res.partner"]
  20. self.partners += self.partners.create({
  21. "name": "consent-partner-0",
  22. "email": "partner0@example.com",
  23. })
  24. self.partners += self.partners.create({
  25. "name": "consent-partner-1",
  26. "email": "partner1@example.com",
  27. })
  28. self.partners += self.partners.create({
  29. "name": "consent-partner-2",
  30. "email": "partner2@example.com",
  31. })
  32. # Partner without email, on purpose
  33. self.partners += self.partners.create({
  34. "name": "consent-partner-3",
  35. })
  36. # Blacklist some partners
  37. self.blacklists = self.env["mail.blacklist"]
  38. self.blacklists += self.blacklists._add("partner1@example.com")
  39. # Activity without consent
  40. self.activity_noconsent = self.env["privacy.activity"].create({
  41. "name": "activity_noconsent",
  42. "description": "I'm activity 1",
  43. })
  44. # Activity with auto consent, for all partners
  45. self.activity_auto = self.env["privacy.activity"].create({
  46. "name": "activity_auto",
  47. "description": "I'm activity auto",
  48. "subject_find": True,
  49. "subject_domain": repr([("id", "in", self.partners.ids)]),
  50. "consent_required": "auto",
  51. "default_consent": True,
  52. "server_action_id": self.sync_blacklist.id,
  53. })
  54. # Activity with manual consent, skipping partner 0
  55. self.activity_manual = self.env["privacy.activity"].create({
  56. "name": "activity_manual",
  57. "description": "I'm activity 3",
  58. "subject_find": True,
  59. "subject_domain": repr([("id", "in", self.partners[1:].ids)]),
  60. "consent_required": "manual",
  61. "default_consent": False,
  62. "server_action_id": self.sync_blacklist.id,
  63. })
  64. def check_activity_auto_properly_sent(self):
  65. """Check emails sent by ``self.activity_auto``."""
  66. consents = self.env["privacy.consent"].search([
  67. ("activity_id", "=", self.activity_auto.id),
  68. ])
  69. # Check pending mails
  70. for consent in consents:
  71. self.assertEqual(consent.state, "draft")
  72. messages = consent.message_ids
  73. self.assertEqual(len(messages), 2)
  74. # Check sent mails
  75. self.cron_mail_queue.method_direct_trigger()
  76. for consent in consents:
  77. self.assertEqual(consent.state, "sent")
  78. messages = consent.message_ids
  79. self.assertEqual(len(messages), 3)
  80. # 2nd message notifies creation
  81. self.assertEqual(
  82. messages[2].subtype_id,
  83. self.mt_consent_consent_new,
  84. )
  85. # 3rd message notifies subject
  86. # Placeholder links should be logged
  87. self.assertTrue("/privacy/consent/accept/" in messages[1].body)
  88. self.assertTrue("/privacy/consent/reject/" in messages[1].body)
  89. # Tokenized links shouldn't be logged
  90. self.assertFalse(consent._url(True) in messages[1].body)
  91. self.assertFalse(consent._url(False) in messages[1].body)
  92. # 4th message contains the state change
  93. self.assertEqual(
  94. messages[0].subtype_id,
  95. self.mt_consent_state_changed,
  96. )
  97. # Partner's is_blacklisted should be synced with default consent
  98. self.assertFalse(consent.partner_id.is_blacklisted)
  99. def test_default_template(self):
  100. """We have a good mail template by default."""
  101. good = self.env.ref("privacy_consent.template_consent")
  102. self.assertEqual(
  103. self.activity_noconsent.consent_template_id,
  104. good,
  105. )
  106. self.assertEqual(
  107. self.activity_noconsent.consent_template_default_body_html,
  108. good.body_html,
  109. )
  110. self.assertEqual(
  111. self.activity_noconsent.consent_template_default_subject,
  112. good.subject,
  113. )
  114. def test_find_subject_if_consent_required(self):
  115. """If user wants to require consent, it needs subjects."""
  116. # Test the onchange helper
  117. onchange_activity1 = self.env["privacy.activity"].new(
  118. self.activity_noconsent.copy_data()[0])
  119. self.assertFalse(onchange_activity1.subject_find)
  120. onchange_activity1.consent_required = "auto"
  121. onchange_activity1._onchange_consent_required_subject_find()
  122. self.assertTrue(onchange_activity1.subject_find)
  123. # Test very dumb user that forces an error
  124. with self.assertRaises(ValidationError):
  125. self.activity_noconsent.consent_required = "manual"
  126. def test_template_required_auto(self):
  127. """Automatic consent activities need a template."""
  128. self.activity_noconsent.subject_find = True
  129. self.activity_noconsent.consent_template_id = False
  130. self.activity_noconsent.consent_required = "manual"
  131. with self.assertRaises(ValidationError):
  132. self.activity_noconsent.consent_required = "auto"
  133. def test_generate_manually(self):
  134. """Manually-generated consents work as expected."""
  135. for partner in self.partners:
  136. if partner.email:
  137. self.blacklists._remove(partner.email)
  138. result = self.activity_manual.action_new_consents()
  139. self.assertEqual(result["res_model"], "privacy.consent")
  140. consents = self.env[result["res_model"]].search(result["domain"])
  141. self.assertEqual(consents.mapped("state"), ["draft"] * 2)
  142. self.assertEqual(
  143. consents.mapped("partner_id.is_blacklisted"),
  144. [False] * 2,
  145. )
  146. self.assertEqual(consents.mapped("accepted"), [False] * 2)
  147. self.assertEqual(consents.mapped("last_metadata"), [False] * 2)
  148. # Check sent mails
  149. messages = consents.mapped("message_ids")
  150. self.assertEqual(len(messages), 2)
  151. subtypes = messages.mapped("subtype_id")
  152. self.assertTrue(subtypes & self.mt_consent_consent_new)
  153. self.assertFalse(subtypes & self.mt_consent_acceptance_changed)
  154. self.assertFalse(subtypes & self.mt_consent_state_changed)
  155. # Send one manual request
  156. action = consents[0].action_manual_ask()
  157. self.assertEqual(action["res_model"], "mail.compose.message")
  158. composer = self.env[action["res_model"]] \
  159. .with_context(active_ids=consents[0].ids,
  160. active_model=consents._name,
  161. **action["context"]).create({})
  162. composer.onchange_template_id_wrapper()
  163. composer.send_mail()
  164. messages = consents.mapped("message_ids") - messages
  165. self.assertEqual(len(messages), 2)
  166. self.assertEqual(messages[0].subtype_id, self.mt_consent_state_changed)
  167. self.assertEqual(consents.mapped("state"), ["sent", "draft"])
  168. self.assertEqual(
  169. consents.mapped("partner_id.is_blacklisted"),
  170. [False, False],
  171. )
  172. # Placeholder links should be logged
  173. self.assertTrue("/privacy/consent/accept/" in messages[1].body)
  174. self.assertTrue("/privacy/consent/reject/" in messages[1].body)
  175. # Tokenized links shouldn't be logged
  176. accept_url = consents[0]._url(True)
  177. reject_url = consents[0]._url(False)
  178. self.assertNotIn(accept_url, messages[1].body)
  179. self.assertNotIn(reject_url, messages[1].body)
  180. # Visit tokenized accept URL
  181. result = self.url_open(accept_url).text
  182. self.assertIn("accepted", result)
  183. self.assertIn(reject_url, result)
  184. self.assertIn(self.activity_manual.name, result)
  185. self.assertIn(self.activity_manual.description, result)
  186. consents.invalidate_cache()
  187. self.assertEqual(consents.mapped("accepted"), [True, False])
  188. self.assertTrue(consents[0].last_metadata)
  189. self.assertFalse(consents[0].partner_id.is_blacklisted)
  190. self.assertEqual(consents.mapped("state"), ["answered", "draft"])
  191. self.assertEqual(
  192. consents[0].message_ids[0].subtype_id,
  193. self.mt_consent_acceptance_changed,
  194. )
  195. # Visit tokenized reject URL
  196. result = self.url_open(reject_url).text
  197. self.assertIn("rejected", result)
  198. self.assertIn(accept_url, result)
  199. self.assertIn(self.activity_manual.name, result)
  200. self.assertIn(self.activity_manual.description, result)
  201. consents.invalidate_cache()
  202. self.assertEqual(consents.mapped("accepted"), [False, False])
  203. self.assertTrue(consents[0].last_metadata)
  204. self.assertTrue(consents[0].partner_id.is_blacklisted)
  205. self.assertEqual(consents.mapped("state"), ["answered", "draft"])
  206. self.assertEqual(
  207. consents[0].message_ids[0].subtype_id,
  208. self.mt_consent_acceptance_changed,
  209. )
  210. self.assertFalse(consents[1].last_metadata)
  211. def test_generate_automatically(self):
  212. """Automatically-generated consents work as expected."""
  213. result = self.activity_auto.action_new_consents()
  214. self.assertEqual(result["res_model"], "privacy.consent")
  215. self.check_activity_auto_properly_sent()
  216. def test_generate_cron(self):
  217. """Cron-generated consents work as expected."""
  218. self.cron.method_direct_trigger()
  219. self.check_activity_auto_properly_sent()
  220. def test_mail_template_without_links(self):
  221. """Cannot create mail template without needed links."""
  222. with self.assertRaises(ValidationError):
  223. self.activity_manual.consent_template_id.body_html = "No links :("