openerp-india team mailing list archive

[Raphaël Valyi - http://www.akretion.com <934242@xxxxxxxxxxxxxxxxxx>]

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" <
934242@xxxxxxxxxxxxxxxxxx> 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 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 just a use case which popped in my head to
> explain why a "test" database can contains real emails, I imagine that many
> others situation may occur.
>
>
> Happy end of release and have a nice week-end
> Guewen
>
> --
> 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
>

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, 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