Poweremail(E-mail capabilities for Tryton).

[shalabh.aggarwal, 2010-05-18 09:27:25]

The initial release for poweremail has been uploaded.

[shalabh.aggarwal, 2010-05-18 09:54:43]

Hi,

Further to the discussion with Mr. Sharoon, we have uploaded the latest code of
poweremail module for review.

Thanks and Regards
The Open Labs Team.

[ced, 2010-05-18 10:17:37]

http://codereview.appspot.com/1208044/diff/1/2
File __init__.py (right):

http://codereview.appspot.com/1208044/diff/1/2#newcode4
__init__.py:4: from poweremail import *
Try to group python file by business logical

http://codereview.appspot.com/1208044/diff/1/2#newcode7
__init__.py:7: from poweremail_send_wizard import *
Don't create python for only wizard, wizard runs on models and so should go with
this model.

http://codereview.appspot.com/1208044/diff/1/3
File __tryton__.py (right):

http://codereview.appspot.com/1208044/diff/1/3#newcode4
__tryton__.py:4: 'name': 'Powerful Email capabilities for Tryton',
The module should be split in at least 4 modules:

- email queue for Tryton server emails (directly in trytond)
- email folders for users
- email reception (even if I don't think it should work like that)
- system email template

http://codereview.appspot.com/1208044/diff/1/3#newcode11
__tryton__.py:11: Power Email - extends the most Power ful open source ERP with
email which powers the world today.
I don't think this is the right place for ads. :-)

http://codereview.appspot.com/1208044/diff/1/3#newcode16
__tryton__.py:16: 2. Company & Personal Email accounts
Company should not have email account

http://codereview.appspot.com/1208044/diff/1/4
File poweremail.py (right):

http://codereview.appspot.com/1208044/diff/1/4#newcode166
poweremail.py:166: '_get_incoming_server': True,
If function must be called from rpc, it should not start by "_"

http://codereview.appspot.com/1208044/diff/1/4#newcode237
poweremail.py:237: :attention: DO NOT USE except_osv IN THIS METHOD
useless comment

[sharoonthomas, 2010-05-18 10:24:30]

Thanks for the comments,

Could you please propose how we could split the whole module ?

Thanks,

[casaxa, 2010-05-18 16:19:26]

http://codereview.appspot.com/1208044/diff/1/3
File __tryton__.py (right):

http://codereview.appspot.com/1208044/diff/1/3#newcode16
__tryton__.py:16: 2. Company & Personal Email accounts
On 2010/05/18 10:17:37, ced wrote:
> Company should not have email account

In my opinion company is ok if it has an e-mail, many companies use info@ or
sales@ or company_name@ e-mails which get delivered to various persons or
programs sometimes. So you dont have only one person who read it.

[sharoonthomas, 2010-05-18 16:33:37]

http://codereview.appspot.com/1208044/diff/1/3
File __tryton__.py (right):

http://codereview.appspot.com/1208044/diff/1/3#newcode16
__tryton__.py:16: 2. Company & Personal Email accounts
From what I have seen so far in poweremail implementations with Open ERP, many
organisations use this feature fo company accounts.

I think it strongly goes with the odea of Implementing IMAP/SMTP over to
facilitate tryton as email server

On 2010/05/18 16:19:26, casaxa wrote:
> On 2010/05/18 10:17:37, ced wrote:
> > Company should not have email account
> 
> In my opinion company is ok if it has an e-mail, many companies use info@ or
> sales@ or company_name@ e-mails which get delivered to various persons or
> programs sometimes. So you dont have only one person who read it.

[ced, 2010-05-18 18:13:44]

On 2010/05/18 10:24:30, sharoonthomas wrote:
> Thanks for the comments,
> 
> Could you please propose how we could split the whole module ?
> 

I suppose that Tryton has a mail queue.

- mailbox: a module that allow to store emails for users almost like in a
maildir (perhaps with the notion of tags like in gmail)
- email_template: a module that allow to send (using mail queue) email based on
template (an email from maildir) and linked to a model using the triggers or a
wizard.
- email_fetch_pop3: a module that allow to fetch emails using pop3 and store
them in maildir
- email_fetch_imap4: a module that allow to fetch emails using imap4 and store
them in maildir
- email_imap4: it will not be a tryton module but more a server script and will
expose maildir through imap4

By the way, with imap protocol you will not have to try to create an email GUI
in Tryton (which will always be less ergonomic than a real one).

PS: I'm not sure about the useful of the email_fetch modules because I think
company has their own email server and a procmail-like script will be better.

[sharoonthomas, 2010-05-18 18:53:36]

I think the splitting looks OK.

But is it not better to have 1 module to do both pop3 and imap4 fetching because
both of them will have mostly the same code and it would be redundant to build
two views for the same. I think they could reuse the same models infact.

regarding, email_fetch modules, I think its important because I have seen it
being really useful (and the fetchmail script of openerp crm is considered its
biggest disadvantage).

Consider generating records from emails. So I think its important! However,
since we will be splitting the modules, the user will have the option to use
this or write a script himself?
On 2010/05/18 18:13:44, ced wrote:
> On 2010/05/18 10:24:30, sharoonthomas wrote:
> > Thanks for the comments,
> > 
> > Could you please propose how we could split the whole module ?
> > 
> 
> I suppose that Tryton has a mail queue.
> 
> - mailbox: a module that allow to store emails for users almost like in a
> maildir (perhaps with the notion of tags like in gmail)
> - email_template: a module that allow to send (using mail queue) email based
on
> template (an email from maildir) and linked to a model using the triggers or a
> wizard.
> - email_fetch_pop3: a module that allow to fetch emails using pop3 and store
> them in maildir
> - email_fetch_imap4: a module that allow to fetch emails using imap4 and store
> them in maildir
> - email_imap4: it will not be a tryton module but more a server script and
will
> expose maildir through imap4
> 
> By the way, with imap protocol you will not have to try to create an email GUI
> in Tryton (which will always be less ergonomic than a real one).
> 
> PS: I'm not sure about the useful of the email_fetch modules because I think
> company has their own email server and a procmail-like script will be better.

[ced, 2010-05-18 20:43:38]

On 2010/05/18 18:53:36, sharoonthomas wrote:
> I think the splitting looks OK.
> 
> But is it not better to have 1 module to do both pop3 and imap4 fetching
because
> both of them will have mostly the same code and it would be redundant to build
> two views for the same. I think they could reuse the same models infact.

You can have a common module with the shared code.

> 
> regarding, email_fetch modules, I think its important because I have seen it
> being really useful (and the fetchmail script of openerp crm is considered its
> biggest disadvantage).

I think that fetching emails from external account is not a good design because
there is duplication of data.
See the wiki about email, the best will be to have a Mail Delivery Agent to push
emails in Tryton.
I think a company that want to have a business vision of his communication will
have his own email server.

> Consider generating records from emails. So I think its important! However,
> since we will be splitting the modules, the user will have the option to use
> this or write a script himself?

You but with the plan to have IMAP access into Tryton server, I really think
that fetching emails from other email service is not efficient. And I think
Tryton should propose the best solution (with possibility to customize).

[udono, 2013-03-27 12:42:15]

can be closed?