You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the create() method of subscription.request, there is this line:
subscription_request._send_confirmation_mail()
I have two objections to this:
Most importantly, programmatically, this is Bad. Odoo already violates this rule a little bit, but constructors shouldn't have side effects beyond creating the thing you want to be created. Sending an e-mail is an especially egregious side effect.
Functionally, this isn't great. The request is created in draft, and I wouldn't expect Odoo to send e-mails of in-draft objects until I click on a button that is semantically equivalent to 'I have finished filling in most/all the fields; this record is no longer in draft'.
The reason, I believe, that this line exists, is for people who submit their subscription request online. The flow is this:
User fills in their details on the online form.
User clicks on 'submit'.
Odoo validates the data.
Assuming it's valid, Odoo creates the request record.
While creating the request record, an e-mail is sent that assures the user that the request was correctly received and that the cooperative will process their request.
To Reproduce
Affected versions: All, I think. 14.0 at least.
Steps to reproduce the behavior:
Create a request.
Expected behavior
I see two obvious solutions:
Add a state after draft. When switching to this state, send the e-mail. The name of this state could be confirmed, processing, sen[d|t], or some such. This implies a change in workflow for people working with this module. There is a reverted commit in [14.0] cooperator: Multi-company e-mail templates #73 that does this.
Just remove the line, and in the cooperator_website code, add a line to send the e-mail after the request is created. This implies a change (reduction) in functionality: confirmation e-mails are no longer sent when requests are manually created in the back-end.
Additional context
Add any other context about the problem here. (e.g. OS, Python version, ...)
The text was updated successfully, but these errors were encountered:
There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.
huguesdk
added
no stale
Use this label to prevent the automated stale action from closing this PR/Issue.
and removed
stale
PR/Issue without recent activity, it'll be soon closed automatically.
labels
Dec 11, 2023
Module
cooperator
Describe the bug
In the
create()
method ofsubscription.request
, there is this line:I have two objections to this:
The reason, I believe, that this line exists, is for people who submit their subscription request online. The flow is this:
To Reproduce
Affected versions: All, I think. 14.0 at least.
Steps to reproduce the behavior:
Expected behavior
I see two obvious solutions:
draft
. When switching to this state, send the e-mail. The name of this state could beconfirmed
,processing
,sen[d|t]
, or some such. This implies a change in workflow for people working with this module. There is a reverted commit in [14.0] cooperator: Multi-company e-mail templates #73 that does this.cooperator_website
code, add a line to send the e-mail after the request is created. This implies a change (reduction) in functionality: confirmation e-mails are no longer sent when requests are manually created in the back-end.Additional context
Add any other context about the problem here. (e.g. OS, Python version, ...)
The text was updated successfully, but these errors were encountered: