EDI Auto-email should not be active by default

[Guewen Baconnier @ Camptocamp]

Hello,

3 emails actions are created when we install the modules sale / account / purchase :
Auto-email confirmed sale orders [1]
Auto-email confirmed invoices [2]
Auto-email confirmed purchase orders [3]

These actions are configured to send a mail to the partners (unless if they have the "opt-out" on) with the document with the EDI system.

I think that it is quite debatable to activate this by default.
In my opinion, this should be set off by default, and afterwards it should be the responsibility of the integrator or user to active this feature or not, because it can have serious effects on the customer base.

But above all, noupdate="1" must be set on the xml! If you deactivate the actions server manually, because you (absolutely) do not want those mails to be send to your customers, next time you update your modules, the server actions will be reactivated ! (and mails will be sent before you see it.)

The question is not on the quality or goodness of this EDI feature, but that's about the control of the mail outputs.

Thanks for your understanding on this topic.

Guewen

[1] http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/view/head:/sale/edi/sale_order_action_data.xml#L5
[2] http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/view/head:/account/edi/invoice_action_data.xml#L5
[3] http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/view/head:/purchase/edi/purchase_order_action_data.xml#L5

[Guewen Baconnier @ Camptocamp (gbaconnier-c2c)]

Moreover this feature will just not work in many cases.
As instance, the customer must have access to the OpenERP's server and it is the most of the time not exposed for security reasons.

So the customer will receive an email which an unreachable email.

Really, I think this should not be activated by default.

Guewen

[Sébastien BEAU - http://www.akretion.com (sebastien.beau)]

+ 1 for guewen
I fully agree that noupdate should be set to "1". If not we will always forget to unactive the option after an update all. Very dangerous behaviour.
Also I think It's better to unactivate the auto-email by default. Indead if an end user test OpenERP and spam all of this customer by error, I am not sure that he will apreciate the 'auto-email' feature.

All I just when to thanks OpenERP SA for this feature that really rock's, the problem is just taking care of not sending email by error.

Best Regards

[Guewen Baconnier @ Camptocamp (gbaconnier-c2c)]

- So the customer will receive an email which an unreachable email.
+ So the customer will receive an email with an unreachable url.

[Olivier Dony (Odoo) (odo-openerp)]

Hello,

Having the auto-email notification enabled by default is a design choice and in fact the only sensible choice for new users. This is simply the natural behavior and having to look for such a feature would be a real usability issue.
Those automatic notifications are only sent when a document is confirmed, not when simply writing draft documents.
However we completely understand that some companies would like to customize them or turn them off, so that is why we included several mechanisms to do so:

- OpenERP setups without a proper Outgoing Email Server (SMTP) setup will not be able to send out any email, and this will presumably be the case when testing (all demo partners are opted-out BTW)
- Customers without an email address will obviously not receive any notification (this will presumably be the case when testing, or perhaps they would have test emails instead)
- Customer who have been opted out will never receive notifications
- Finally, you can not only customize the templates but you can also delete them completely or remove the binding of the action for sending them from the corresponding workflow - and that is *permanent*

So yes, we have defined the templates and the action bindings in NOUPDATE blocks from the very beginning - just look 25 lines below the places in the code you mentioned, and you will see very obvious comments about this[1], e.g.:

    <!-- Mail template and workflow bindings are done in a NOUPDATE block
         so users can freely customize/delete them -->

Deleting the action itself is unnecessary and would actually make it harder to re-enable the feature later. Instead the cleanest thing to do is to remove the action bindings from the corresponding workflow activities, and they won't be automatically re-installed. *And* you can easily re-bind them later as needed.

As for non-technical OpenERP users who don't know how to customize workflows, they can simply opt-out customers or delete the templates altogether - much easier than having to find an action to delete.

[1] http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/view/head:/account/edi/invoice_action_data.xml#L29

[Guewen Baconnier @ Camptocamp (gbaconnier-c2c)]

Hello,

Thanks for your response.

Ok , good point for the workflow binding. This resolve my point 2 which is to disable this feature.

I immediately felt that it was a deliberate and conscious design choice and I can understand it in the substance. I anticipated your response, as OpenERP SA's goal is to have a viral ERP so it needs this feature activated on as much servers as possible (am I wrong?).
I also think you already debated it quite a lot internally, so I probably won't change the situation.

But I nevertheless want to explain my position, I still think this must not be active by default, why ?

If you configure the SMTP for any other reason (usage of CRM as instance) and are not really aware of this auto-email actions server, the mails will be sent. (RTCH, Read the Fucking Change Log ?)

When you setup an ERP server, actually, you expose it as little as possible to the world wide. It may be often intern to the enterprise's network, or extern with a security (domain restriction, vpn, ...). This situation may change, seemingly OpenERP bets on this and wants to exposes a part of the ERP to the world wide. I do agree that the new viral features you develop are great ideas, very cool and promising (share, EDI).

But what happens when an EDI Auto-email is sent? It contains an URL to reach the ERP and download the document. This URL will work perfectly on your SAAS, but on an enterprise, closed, server, the url will not be reachable / granted.

This isn't a problem in itself, if we accept the risk to expose the server, the infrastructure can be configured the right way to achieve that. But that means it needs configuration, it needs a conscious work in order to get the EDI features work correctly. So what I mean here is that the auto-emails should be deactivated by default, and the activation should be the final step of all this setup.
I really would like to know the percentage of servers for which the auto-email would work out of the box, I don't think it is very high. So what's the point to activate a feature which will malfunction in most of cases ? (but maybe I'm wrong, it's impossible to have this statistic)

If I understood well, the idea is to have a viral ERP. So people must activate this feature, otherwise it can't work. You maybe assume that if it is deactivated by default, people will never activate it. Maybe you are right.
But on another side, I wonder if having an auto-email which will be broken in most of cases (see above) is not worse.

Hope I'm wrong.

And just a side note on :
"Customers without an email address will obviously not receive any notification (this will presumably be the case when testing, or perhaps they would have test emails instead)"
An example of situation : People are trying magentoerpconnect (and I can assure you that this module is THE point which decided some customers to choose OpenERP vs other ERPs, this is an entry point), they synchronize all their customer base with OpenERP and do some tests to evaluate the module. All their customers will have a *real* email. So I hope they will not try to confirm an order. Ok I have to admit that in this case the smtp won't probably be setup, but this was ju...

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello, unfortunately I agree with Guewen. Also here in Brazil SMB's don' t
use EDI so we are screwed by default...
Finally, I suggest you weight the bet benrfit between 1) doing wrong
annoying things by default and 2) being viral. Honnestly I bet the net
benefit is negative if you do such bad things by default. It's just like
spamming: yes it's viral but no it doesn't help to build a strong brand...

I bet my money it will be like the dashboard by default thing: you'll end
up dropping them. Well maybe you could do it right directly without having
to go for that whole process for a year or more.

Don' t get me wrong this is probably a nice feature where it' s used and
for internet exposed servers, but this is just the default that sucks. If
it so useful, people would activate it don't worry..
On Feb 17, 2012 8:05 PM, "Guewen Baconnier @ Camptocamp" <
<email address hidden>> wrote:

> Hello,
>
> Thanks for your response.
>
> Ok , good point for the workflow binding. This resolve my point 2 which
> is to disable this feature.
>
> I immediately felt that it was a deliberate and conscious design choice
> and I can understand it in the substance. I anticipated your response, as
> OpenERP SA's goal is to have a viral ERP so it needs this feature activated
> on as much servers as possible (am I wrong?).
> I also think you already debated it quite a lot internally, so I probably
> won't change the situation.
>
> But I nevertheless want to explain my position, I still think this must
> not be active by default, why ?
>
> If you configure the SMTP for any other reason (usage of CRM as
> instance) and are not really aware of this auto-email actions server,
> the mails will be sent. (RTCH, Read the Fucking Change Log ?)
>
> When you setup an ERP server, actually, you expose it as little as
> possible to the world wide. It may be often intern to the enterprise's
> network, or extern with a security (domain restriction, vpn, ...). This
> situation may change, seemingly OpenERP bets on this and wants to
> exposes a part of the ERP to the world wide. I do agree that the new
> viral features you develop are great ideas, very cool and promising
> (share, EDI).
>
> But what happens when an EDI Auto-email is sent? It contains an URL to
> reach the ERP and download the document. This URL will work perfectly on
> your SAAS, but on an enterprise, closed, server, the url will not be
> reachable / granted.
>
> This isn't a problem in itself, if we accept the risk to expose the
> server, the infrastructure can be configured the right way to achieve that.
> But that means it needs configuration, it needs a conscious work in order
> to get the EDI features work correctly. So what I mean here is that the
> auto-emails should be deactivated by default, and the activation should be
> the final step of all this setup.
> I really would like to know the percentage of servers for which the
> auto-email would work out of the box, I don't think it is very high. So
> what's the point to activate a feature which will malfunction in most of
> cases ? (but maybe I'm wrong, it's impossible to have this statistic)
>
> If I understood well, the idea is to have a viral ERP. So people...

[Graeme Gellatly (gdgellatly)]

Of course the other solution is to change the name opt-out to opt-in and
reverse the server action logic. It is more in line with anti-spam and
permission based marketing laws and codes anyway. But yes noupdate must be
set. Actually on the subject of antispam, why does everytime I test a bug
using openerp demo platform do I get spam from indian openerp partners?

On Sat, Feb 18, 2012 at 4:26 AM, Guewen Baconnier @ Camptocamp <
<email address hidden>> wrote:

> - So the customer will receive an email which an unreachable email.
> + So the customer will receive an email with an unreachable url.
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Addons.
> https://bugs.launchpad.net/bugs/934242
>
> Title:
> EDI Auto-email
>
> Status in OpenERP Addons (modules):
> New
>
> Bug description:
> Hello,
>
> 3 emails actions are created when we install the modules sale / account /
> purchase :
> Auto-email confirmed sale orders [1]
> Auto-email confirmed invoices [2]
> Auto-email confirmed purchase orders [3]
>
> These actions are configured to send a mail to the partners (unless if
> they have the "opt-out" on) with the document with the EDI system.
>
> I think that it is quite debatable to activate this by default.
> In my opinion, this should be set off by default, and afterwards it
> should be the responsibility of the integrator or user to active this
> feature or not, because it can have serious effects on the customer base.
>
> But above all, noupdate="1" must be set on the xml! If you deactivate
> the actions server manually, because you (absolutely) do not want
> those mails to be send to your customers, next time you update your
> modules, the server actions will be reactivated ! (and mails will be
> sent before you see it.)
>
> The question is not on the quality or goodness of this EDI feature,
> but that's about the control of the mail outputs.
>
> Thanks for your understanding on this topic.
>
> Guewen
>
> [1]
> http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/view/head:/sale/edi/sale_order_action_data.xml#L5
> [2]
> http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/view/head:/account/edi/invoice_action_data.xml#L5
> [3]
> http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/view/head:/purchase/edi/purchase_order_action_data.xml#L5
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/934242/+subscriptions
>

[Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c)]

Hi Olivier,

I must say that I completely agree with Guewen here. Being viral is great and we're all behind you on that point. But as in most of the case this features won't work, it will just give a poor impression of the tools.

This do not deserve at all the hard work we all make to build such a great tools as OpenERP is !

Moreover, in some specific case (like the case of people testing magentoerpconnect, but not only), it will just be a disaster. You will just spam the whole customer database.

I like the idea of making an "opt-in" instead of an "opt-out" and noupdate=1 (as Graeme suggested in #7). This will just be the perfect solution where everyone will be happy. The functionally will be there, but you'll have to say for who.

Please, reconsider this before release.

Kind regards,

Joël

[Stefan Rijnhart (Opener) (stefan-opener)]

+1

Please implement customer opt-in or allow global control (e.g. in Company settings).

Cheers,
Stefan.

[Guewen Baconnier @ Camptocamp (gbaconnier-c2c)]

To focalize the discussion:

The noupdate=0 on the action server is not a problem, as Olivier
explained, a noupdate=1 has been put on purpose on the binding
workflow-action server.

It stays the issue of the edi auto-emails activated by default even though
it will be broken on the most of the OpenERP servers out of the box.

For the time being, 2 propositions have been done :
- deactivate it by default and let the responsibility to the integrator /
user to activate it once he is sure that the pre-requisite configuration is
done (server exposed and reachable via the url sent to the customers).

- reverse the actual logic of "opt-out" by a "opt-in" field so any partner
can receive an edi auto-emails before it has been explicitly activated on
it. It may also be more in phase with marketing laws and codes (comment #7)
.

Thanks all for your views.

Guewen

[Nicolas Bessi - Camptocamp (nbessi-c2c-deactivatedaccount)]

Hello,

In an ERP as is any system one of the golden rule is that user should have control on all "output" of a system. We do not like when services or phones APP send mail or transmit our personal data without asking us.

Here it is the same, we do not want our system to generate output without our explicit authorization. OpenERP has a nice configuration panel. The activation of EDI mail should be set in a step of configuration wizard that is explicit and where check box is not checked by default.

An other problem is that EDI expose your ERP address if ERP is not accessible to public the link proposed in mail will lead to error message. That not good in term of image. An ERP is a critical application having his address propagated trough e-mail may be a security threat.

EDI is a great tool especially in term of B2B and is clearly a great advantage. But sale orders, purchase ordesr and invoices are highly strategic information and they should be really manage with care.

IMHO at that timeEDI layout of mail, and default security mechanism are mature enough to use it without taking other infrastructure reinforcement and tweak.

Regards

Nicolas

[James Jesudason (jamesj)]

I agree with Nicolas (#11) - sending emails by default from an ERP system is a bad idea.

[Alan Lord (theopensourcerer)]

+1. This should not be enabled by default! In the UK I know customers (and people who try OpenERP for the first time) will be really annoyed if it starts sending emails eveywhere.

[Stefan Rijnhart (Opener) (stefan-opener)]

Hi,

although it does not solve the problem of these emails being enabled by default in every OpenERP 6.1 database, Therp provides a set of small modules to easily disable this functionality with a checkbox on the company form.

    edi_company_control_invoice
    edi_company_control_sale
    edi_company_control_purchase

Get them here: http://bazaar.launchpad.net/~therp-nl/therp-addons/6.1/files or in about a week's time on the Apps site.

Cheers,
Stefan.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hey Stefan, it's like my *_no_dashboard modules... (like sale_no_dashboard)
which many people said it saved their day.
Looks like we have to make modules to work around every dubious default
feature choice...
That would be cool if one day module would mean additional useful feature
and not monkey patch in 50% of the cases...

On Sun, Feb 26, 2012 at 7:22 AM, Stefan Rijnhart (Therp) <
<email address hidden>> wrote:

> Hi,
>
> although it does not solve the problem of these emails being enabled by
> default in every OpenERP 6.1 database, Therp provides a set of small
> modules to easily disable this functionality with a checkbox on the
> company form.
>
> edi_company_control_invoice
> edi_company_control_sale
> edi_company_control_purchase
>
> Get them here: http://bazaar.launchpad.net/~therp-nl/therp-
> addons/6.1/files or in about a week's time on the Apps site.
>
> Cheers,
> Stefan.
>
> --
> You received this bug notification because you are a member of OpenERP
> Drivers, which is subscribed to OpenERP Addons.
> https://bugs.launchpad.net/bugs/934242
>
> Title:
> EDI Auto-email should not be active by default
>
> Status in OpenERP Addons (modules):
> Opinion
>
> Bug description:
> Hello,
>
> 3 emails actions are created when we install the modules sale / account /
> purchase :
> Auto-email confirmed sale orders [1]
> Auto-email confirmed invoices [2]
> Auto-email confirmed purchase orders [3]
>
> These actions are configured to send a mail to the partners (unless if
> they have the "opt-out" on) with the document with the EDI system.
>
> I think that it is quite debatable to activate this by default.
> In my opinion, this should be set off by default, and afterwards it
> should be the responsibility of the integrator or user to active this
> feature or not, because it can have serious effects on the customer base.
>
> But above all, noupdate="1" must be set on the xml! If you deactivate
> the actions server manually, because you (absolutely) do not want
> those mails to be send to your customers, next time you update your
> modules, the server actions will be reactivated ! (and mails will be
> sent before you see it.)
>
> The question is not on the quality or goodness of this EDI feature,
> but that's about the control of the mail outputs.
>
> Thanks for your understanding on this topic.
>
> Guewen
>
> [1]
> http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/view/head:/sale/edi/sale_order_action_data.xml#L5
> [2]
> http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/view/head:/account/edi/invoice_action_data.xml#L5
> [3]
> http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/view/head:/purchase/edi/purchase_order_action_data.xml#L5
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/934242/+subscriptions
>

[Kyle Waid (midwest)]

+1 no default emails

[jacobdotcosta (jacob-costa)]

I have to

+1 no default emails...

...because I just received an email from a client stating he couldn't download an invoice which my openERP just sent. Fortunately he couldn't because I'm still implementing openERP, and learning along the way, and the invoice wasn't correct yet.

[TArpi (teksearpi)]

+1 no default emails

Recently, I wanted to test the email feature of 6.1.1. oErp.
I copied a working db to a test, and I set up the incoming mail server with all the setting it should.
Then, for the first time I looked in the Setting/Config/Email/ Messages. Than I saw all my confirmed PO's and SO's auto emails in "Delivery failed" state.
If I set up the outgoing mail account in the beginning, than every SO an PO after confirmation, would automatically fly away without my knowledge, to the partners. However we sent them manually. So this means they would have received two times.
I think this isn't correct.

Or if this feature is automatic, than every time a mail should be sent, the system should warn the user. Of course with the possibility to disable that warning.

TArpi

[conexus - s.petersen (s.petersen)]

+1 no default emails, that's also our opinion

[Mikkel Christensen (mbc-baekhoej)]

Developers, thank you very much for your work on this very large and capable piece of software that is OpenERP. Most of it works very well, although the learning curve is steep.

I found this bug report in my search for a way to disable auto-email - after finding out to my absolute horror that OpenERP was sending out emails to customer email addresses without my knowledge!!!

This feature should *absolutely not*, *never* *ever*, be enabled by default! It boggles my mind how anyone could think that it is a good idea.

- Anybody starting out with OpenERP is 99% likely to be unaware that it will start sending out emails by default.
- Anybody who actually wants this feature will want to configure it before enabling it.

We are talking about emails to customers. This is always a very sensitive thing and should be treated with extreme care. Every detail in an email to a customer must be correct, polite and thought through carefully, or it will damage your reputation and customer relation.

The email that OpenERP sends out by default - unless the user has made the conscious choice to configure the templates and the system carefully - is:

- Alleging that the customer owes you money (it's an invoice). In the best case, the invoice is real, but is sent twice, because the OpenERP user is unaware of the auto-email feature. In the more likely case, the invoice was just a test while the user is learning about OpenERP and sending such an invoice to a customer could cause serious insult!

- Containing wrong links. Most users would not have their OpenERP publicly accessible from the beginning. The link won't work, which is both unprofessional but also lucky because it gives the customer a hint that something is wrong with a system somewher.

- Probably containing wrong text. Does the normal user really have an online payment portal? And who wouldn't want to customise the text in their letters to the customer.

This feature should NOT be enabled until the user has made the proper preparations and a conscious choice to enable it.

[Florent (florent.x)]

Of course this is an additional configuration step when bootstrapping a new openerp instance...
The issue here is that every company which installs OpenERP is not aware of this "feature"...

We fixed it with these lines in our specific module.

<?xml version="1.0" encoding="utf-8"?>
<openerp>
    <data>

        <!-- Do not send email for each invoice -->
        <delete id="account.ir_actions_server_edi_invoice" model="ir.actions.server"/>

  </data>
</openerp>

[Carlos Liebana (carlos-liebana)]

+1 Guewen

[Nhomar - Vauxoo (nhomar)]

Why not simply "Ask the user" and not believe as SAP guys that always all choices behind scenes are good enought by default.

One of the best things i receive with v6.1 is the EDI feature, but instead put by default, you can invest 2 hours in explain very well how it works and how enable it.

if openerpdoocument and newfeaturesAskByDefault:
    Everybody will be happy
else:
    New People will be worried for Security and we developers expend X hour one by one to disabled this security holes.

In the best case, it will not work if you dont configure emails, but you expend server resources trying to send failed emails.

+1 NO DEFAULT SEND ANY EMAIL.

Ideas:

Opt1: Make a module that auto_configure edi and others emails.
Opt2: Document how it works as soon as you develop and put in production make marketing about it.

BOth results will increase Wuality of service and first impresion IMHO.

Good Job team!

[Lorenzo Battistini (elbati)]

Hello,
we made a simple module 'partner_optout_enable' http://apps.openerp.com/addon/7418 that enables the opt-out field for every new created partner.

[Ana Juaristi Olalde (ajuaristio)]

+1 no default emails
+1 Guewen
+1 Mikkel Christensen (mbc-baekhoej)

[Gianluca Gori @ LS (gaga)]

+1 Guewen