IRC logs of #tryton for Saturday, 2010-05-22 #tryton log beginning Sat May 22 00:00:02 CEST 2010
2010-05-22 00:24 -!- udono( has joined #tryton
2010-05-22 03:31 -!- ikks_(~ikks@ has joined #tryton
2010-05-22 04:58 -!- rednul(~rednul@ has joined #tryton
2010-05-22 05:13 -!- rednul(~rednul@ has joined #tryton
2010-05-22 05:20 -!- yangoon( has joined #tryton
2010-05-22 06:27 -!- mr_amit(~amit@ has joined #tryton
2010-05-22 07:37 -!- rednul(~rednul@ has joined #tryton
2010-05-22 09:18 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton
2010-05-22 09:28 -!- enlightx( has joined #tryton
2010-05-22 09:57 -!- eLBati(~elbati@ has joined #tryton
2010-05-22 10:53 -!- mr_amit(~amit@ has joined #tryton
2010-05-22 11:01 -!- Timitos(~timitos@ has joined #tryton
2010-05-22 13:00 -!- tekknokrat(~lila@ has joined #tryton
2010-05-22 13:13 -!- mr_amit(~amit@ has joined #tryton
2010-05-22 13:48 -!- sharoon( has joined #tryton
2010-05-22 13:49 <sharoon> hi cedk
2010-05-22 13:49 <cedk> sharoon: hi
2010-05-22 13:50 <sharoon> cedk: can we discuss the email blueprint and existing implementation
2010-05-22 13:50 <cedk> sharoon: first, did you test the trigger implemntation ?
2010-05-22 13:50 <sharoon> cedk: not yet
2010-05-22 13:50 <cedk> sharoon: just two minutes, I have a phone call
2010-05-22 13:50 <sharoon> cedk: ok, i will prepare an agenda now
2010-05-22 13:55 <sharoon> cedk: 1. Splitting of Module
2010-05-22 13:55 <sharoon> 2. Accounts configuration - SMTP/IMAP
2010-05-22 13:55 <sharoon> 2.a) Company Accounts
2010-05-22 13:55 <sharoon> 2.b) Scheduler/Cron
2010-05-22 13:55 <sharoon> 3. Mailbox/email queue
2010-05-22 13:55 <sharoon> 3.a) What goes into core?
2010-05-22 13:55 <sharoon> 3.b) Scheduler/Cron
2010-05-22 13:55 <sharoon> 4. Templating
2010-05-22 13:55 <sharoon> 4.a) Mako + Django
2010-05-22 13:56 <sharoon> 4.b) Genshi?
2010-05-22 13:56 <sharoon> 5. Legacy Support?
2010-05-22 13:56 <sharoon> 6. IMAP4/SMTP - Twisted ?
2010-05-22 13:57 -!- ikks_(~ikks@ has joined #tryton
2010-05-22 14:00 <cedk> ACTION back
2010-05-22 14:01 <cedk> sharoon: I will send an email on mailing list to inform about this talk
2010-05-22 14:01 <sharoon> cedk: ok, and we schedule a time?
2010-05-22 14:01 <cedk> sharoon: as you want
2010-05-22 14:01 <cedk> sharoon: it can be now for me
2010-05-22 14:01 <sharoon> cedk: ok, we start then after 5 mins from mail
2010-05-22 14:02 <cedk> sharoon: ok
2010-05-22 14:05 <cedk> sharoon: send
2010-05-22 14:06 <sharoon> cedk: just tweeted about it as well
2010-05-22 14:06 <sharoon> cedk: lets start at 14:10 CEST
2010-05-22 14:07 <cedk> sharoon: yes it is in the email
2010-05-22 14:07 <sharoon> cedk: cool
2010-05-22 14:11 <cedk> ok at my clock it is 14:10
2010-05-22 14:11 <sharoon> cedk: i guess its time and we start?
2010-05-22 14:11 <sharoon> 1. Splitting of Module
2010-05-22 14:12 <cedk> I think we should make modules that do one thing
2010-05-22 14:12 <sharoon> ok
2010-05-22 14:12 <sharoon> so the module needs to be split and we need to decide what goes into what
2010-05-22 14:12 <sharoon> and possible sensible names too
2010-05-22 14:12 <cedk> like that we can change the behavior easily because you must always think about how to customize the code
2010-05-22 14:12 <sharoon> agree
2010-05-22 14:13 <cedk> also it is simplier to develop
2010-05-22 14:13 <cedk> and to test with unittest
2010-05-22 14:13 <sharoon> yep
2010-05-22 14:13 <sharoon> ok so what are the modules
2010-05-22 14:13 <sharoon> 1. email_queue (core)
2010-05-22 14:14 <sharoon> 2. email_configuration
2010-05-22 14:14 <sharoon> 3. email_template
2010-05-22 14:14 <cedk> for me there is at least 4 concept in poweremail
2010-05-22 14:14 <sharoon> ok
2010-05-22 14:15 <cedk> - the storage of email
2010-05-22 14:15 <cedk> like a maildir
2010-05-22 14:15 <sharoon> yep
2010-05-22 14:15 <cedk> the storage must be linked to res.user
2010-05-22 14:15 <sharoon> can you explain?
2010-05-22 14:16 <cedk> so there is folders (or tags) linked to a user (or many) and emails are linked to one or many folders
2010-05-22 14:16 <sharoon> yes
2010-05-22 14:16 <cedk> and folders can have a tree structure
2010-05-22 14:16 <sharoon> ok
2010-05-22 14:16 <sharoon> folders == IMAP folders ?
2010-05-22 14:17 <cedk> no necessary, we must not think about protocols now
2010-05-22 14:17 <sharoon> ok
2010-05-22 14:17 <cedk> it could have some special folders
2010-05-22 14:17 <cedk> like a folder with sended emails
2010-05-22 14:18 <sharoon> ok
2010-05-22 14:18 <cedk> or a folder with new emails
2010-05-22 14:18 <sharoon> Inbox|Archive|Sent|Outbox|Drafts
2010-05-22 14:18 <sharoon> i think these could be the only defaults
2010-05-22 14:18 <sharoon> rest is user defined
2010-05-22 14:18 <cedk> I'm not sure we must fixed the names
2010-05-22 14:19 <sharoon> it might be necessary because only mails in queue and with folder outbox will be sent by the cron job
2010-05-22 14:19 <cedk> I don't think we need of Archive, Outbox nor Drafts
2010-05-22 14:20 <cedk> I'm not agree, this is not how emails are design
2010-05-22 14:20 <sharoon> ok
2010-05-22 14:20 <sharoon> can you explain?
2010-05-22 14:20 <cedk> sending email is an other thing and is not linked to the user's folders
2010-05-22 14:21 <sharoon> ok
2010-05-22 14:21 <cedk> that is why you must define POP/IMAP accounts and also SMTP
2010-05-22 14:21 <sharoon> ok
2010-05-22 14:21 <cedk> in email clients
2010-05-22 14:21 <cedk> and in this module we have only storage functionality
2010-05-22 14:21 <sharoon> ok
2010-05-22 14:21 <cedk> so it will have only INBOX
2010-05-22 14:22 <sharoon> ok
2010-05-22 14:22 <cedk> because to store we need to have a default folder
2010-05-22 14:22 <sharoon> ok
2010-05-22 14:22 <cedk> that is all for the first concept
2010-05-22 14:23 <cedk> - second concept: email sending
2010-05-22 14:23 <sharoon> ok
2010-05-22 14:23 <cedk> sending email means queuing the emails and send it
2010-05-22 14:23 <cedk> all emails goes into the same queue
2010-05-22 14:24 <sharoon> ok
2010-05-22 14:24 <cedk> for the sending, there is 2 possibilities:
2010-05-22 14:24 -!- paepke( has joined #tryton
2010-05-22 14:24 <cedk> - it forward all to a real email server like postfix, sendmail etc.
2010-05-22 14:25 <cedk> - it connect to the dest server and deliver it
2010-05-22 14:25 <cedk> I think the second one is a complex task
2010-05-22 14:25 <sharoon> second is complex
2010-05-22 14:25 <cedk> but we should design the software to be able to do both
2010-05-22 14:25 <sharoon> ok
2010-05-22 14:25 <sharoon> i think for first version leave only option 1
2010-05-22 14:25 <sharoon> but provision for 2 is left
2010-05-22 14:26 <cedk> sharoon: agree
2010-05-22 14:26 <sharoon> ok, now to the design
2010-05-22 14:26 <cedk> and Tryton has already configuration for a smtp connection
2010-05-22 14:27 <sharoon> ah! thats something that needs review
2010-05-22 14:27 <sharoon> i think it should be possible for defining email accounts for each database
2010-05-22 14:27 <sharoon> and for each user
2010-05-22 14:27 <sharoon> if he wishes to
2010-05-22 14:27 <cedk> sharoon: what do you call email accounts?
2010-05-22 14:27 <sharoon> cedk: SMTP/IMAP/POP3 connections
2010-05-22 14:28 <cedk> you must not handle SMTP with IMAP/POP
2010-05-22 14:28 <sharoon> cedk: nope
2010-05-22 14:28 <cedk> this is different purpose
2010-05-22 14:28 <sharoon> SMTP and IMAP/POP3
2010-05-22 14:28 <cedk> I think Tryton must choose to always send email with SMTP
2010-05-22 14:29 <sharoon> yes, only SMTP is planned to be built
2010-05-22 14:29 <sharoon> but are we talkng about the builtin SMTP?
2010-05-22 14:29 <sharoon> thats set in the config?
2010-05-22 14:29 <cedk> yes
2010-05-22 14:29 <sharoon> i think that may not suffice
2010-05-22 14:29 <cedk> I think it is enough
2010-05-22 14:30 <sharoon> Reason: the tryton server gets the SMTP settings
2010-05-22 14:30 <sharoon> not the database
2010-05-22 14:30 <cedk> sharoon: what is the case you think it is not enough, I will explain how to do it :-)
2010-05-22 14:30 <sharoon> so if a Tryton using organisation has multiple companies in separate databases but same server then it will not be possible to use their preferred acoount
2010-05-22 14:31 <sharoon> for example: you have both and address
2010-05-22 14:31 <sharoon> and assume that both are two companies
2010-05-22 14:31 <sharoon> if you want to use these accounts then you need to have two instances of server right?
2010-05-22 14:32 <cedk> sharoon: what do you name accounts ?
2010-05-22 14:32 <sharoon> ACTION am i missing something
2010-05-22 14:32 <sharoon> accounts are email accounts
2010-05-22 14:32 <cedk> sharoon: what is email accounts ? :-)
2010-05-22 14:32 <sharoon> and are two accounts
2010-05-22 14:32 <cedk> sharoon: no it is 2 addresses
2010-05-22 14:33 <cedk> I think you want to express the fact that you want to use 2 different SMTP outgoing server per domain
2010-05-22 14:33 <cedk> am I right
2010-05-22 14:33 <sharoon> cedk: lets use a common tool for reference
2010-05-22 14:33 <sharoon> cedk: lets use the lingua of evolution or thunderbird
2010-05-22 14:34 <sharoon> cedk: whichever u prefer because it makes it easy and common for everybody (even non techies) to understand
2010-05-22 14:34 <cedk> sharoon: if you want but both application doesn't show you how emails are processed
2010-05-22 14:35 <sharoon> cedk: that was for the lingua
2010-05-22 14:35 <sharoon> cedk: like 'accounts' and 'addresses'
2010-05-22 14:35 <cedk> common email configuration in companies are one domain with one smtp server
2010-05-22 14:35 <sharoon> cedk: that suffices for common job like... in django we use it for sending crash reports etc
2010-05-22 14:36 <sharoon> cedk: but to actually send emails companies and users prefer to use either personal accounts
2010-05-22 14:36 <cedk> sharoon: if you refer to thunderbird accounts is only IMAP/POP and SMTP is a separated configuration
2010-05-22 14:36 <sharoon> ACTION thunderbird is now the official reference for lingua
2010-05-22 14:36 <cedk> sharoon: I still don't understand why you talk about personal accounts for email sending
2010-05-22 14:37 <cedk> sharoon: you could have authentication for SMTP connection but that is all
2010-05-22 14:37 <sharoon> cedk: in our company, we have two people for support
2010-05-22 14:38 <cedk> you don't require to have an 'email account' (thunderbird def) to send emails
2010-05-22 14:39 <cedk> sharoon: ok, and I'm pretty sure that they use the same SMTP server
2010-05-22 14:39 <sharoon> yes, but with authentication
2010-05-22 14:39 <cedk> sharoon: because they connect to it from PC, but here it is the Tryton server that will connect to it and that need to be authenticated
2010-05-22 14:40 <sharoon> cedk: but two different domain?
2010-05-22 14:41 <cedk> sharoon: that is not a problem with a good configuration of the smtp server
2010-05-22 14:41 <sharoon> can you explain? how do you configure smtp to talk to two different servers?
2010-05-22 14:41 <cedk> sharoon: you must know that the FROM in email is not linked to the authentication on the SMTP server
2010-05-22 14:41 <cedk> sharoon: don't understand last question
2010-05-22 14:42 <sharoon> cedk: for example assume that a company uses google apps (like we use)
2010-05-22 14:43 <cedk> sharoon: bad :-)
2010-05-22 14:43 <sharoon> cedk: then one db will connect to with the authentication of individual user
2010-05-22 14:43 <sharoon> cedk: agree on the bad ;)
2010-05-22 14:43 <cedk> sharoon: what is the domain ?
2010-05-22 14:44 <cedk> sharoon: or custom one ?
2010-05-22 14:44 <sharoon> cedk:
2010-05-22 14:44 <paepke> cedk, disagree: from in email could be linked to an authenticated user. from could be rewritten or the mail could be dropped. its not common in the wild, but i know some setups.
2010-05-22 14:44 <sharoon> that is the factor with SMTP servers with authentication
2010-05-22 14:44 <cedk> sharoon: according to dig -t TXT you can send email with FROM * from any server
2010-05-22 14:45 <sharoon> ACTION disastrous!
2010-05-22 14:46 <cedk> paepke: yes, you can customize your SMTP server to do any thing but this is configuration
2010-05-22 14:46 <cedk> paepke: but you must configure your SMTP server to work with your applications
2010-05-22 14:46 <sharoon> cedk: when a company owns the SMTP server then its fine
2010-05-22 14:47 <sharoon> cedk: what if it doesnt? as with many cases
2010-05-22 14:47 <paepke> cedk, i agree with sharoon.
2010-05-22 14:47 <cedk> sharoon: smtp server cost nothing to install on the same host than Tryton
2010-05-22 14:48 <sharoon> cedk: but that introduces a new change in an organisation for nothing worth it
2010-05-22 14:48 <sharoon> cedk: and additional headache if they use hosted
2010-05-22 14:49 <sharoon> cedk: hosted mail service or exchange etc
2010-05-22 14:49 <Timitos> cedk: i also agree with sharoon
2010-05-22 14:50 <cedk> ok, I will explain my big plan :-)
2010-05-22 14:51 <cedk> my vision of emails in Tryton is:
2010-05-22 14:51 <cedk> to store all user emails
2010-05-22 14:51 <cedk> but not send it
2010-05-22 14:51 <cedk> sending will be done by the email client of the user
2010-05-22 14:52 <cedk> (with his own "email account"
2010-05-22 14:52 <cedk> so Tryton doesn't require to know the "email account" of users as it will not send emails
2010-05-22 14:53 <cedk> this way, we will have all the emails of a company stored in Tryton then we could process it
2010-05-22 14:53 <sharoon> cedk: i think it will be bad design because, it has the current problem with the Open ERP thunderbird interface.... when everything becomes hosted & cloud based, we should not base designs on applications like a desktop email client. Also this has disadvantages when a web client is used and access could be from anywhere?
2010-05-22 14:53 <cedk> like link it to party (for crm case)
2010-05-22 14:54 <cedk> sharoon: if you want email client in web interface then you can go for software like horde etc.
2010-05-22 14:54 <Timitos> cedk: what about email that will be created by the tryton server like a confirmation email?
2010-05-22 14:55 <cedk> sharoon: and I don't say to use something like thunderbird OpenERP interface
2010-05-22 14:55 <cedk> sharoon: it will work out of the box for any email client (with IMAP support)
2010-05-22 14:55 <paepke> cedk, so sending an invoice via email would mean that the user has to be in front of the computer and pressing the "send" button in tryton to pop up the mail client and press there send, too?
2010-05-22 14:55 <cedk> Timitos: then it is an email sended by the Tryton server so it will use Tryton server account
2010-05-22 14:55 <cedk> Timitos: define in the configuration
2010-05-22 14:56 -!- saxa( has joined #tryton
2010-05-22 14:56 <sharoon> cedk: but the question remain in such a design: how do you send from different accounts
2010-05-22 14:56 <cedk> paepke: it depends of what you name sending an invoice via email
2010-05-22 14:56 <sharoon> cedk: that is currently possible with the print and email as well right?
2010-05-22 14:56 <cedk> paepke: if you talk about an automatic process then it is the server jobs
2010-05-22 14:56 <Timitos> cedk: what about a multidatabase solution? maybe i do need two different mailservers.
2010-05-22 14:57 <sharoon> cedk: what Timitos has said is according to me the biggest bad in such a design
2010-05-22 14:57 <cedk> paepke: if you talk about salesman sending an invoice then it is with the salesman email client
2010-05-22 14:57 <sharoon> cedk: what about automatic emails?
2010-05-22 14:57 <cedk> sharoon: print-send yes
2010-05-22 14:57 <sharoon> cedk: it actually becomes a manual email then?
2010-05-22 14:57 <cedk> Timitos: no one server can be configured to handle both
2010-05-22 14:58 <cedk> sharoon: automatic emails are sent by Tryton server with Tryton server account
2010-05-22 14:58 <paepke> cedk, yes (salesmen). but its preferrable to have even in automated invoices the sender adress of the responsible salesman. not a standard no-reply@tryton.local
2010-05-22 14:59 <sharoon> cedk: thats a major major requirement!
2010-05-22 14:59 <cedk> paepke: yes but it can be set with the X-REPLY-TO
2010-05-22 14:59 <cedk> sharoon: what?
2010-05-22 15:00 <sharoon> cedk: can you explain how it happens in the case of some service like exchange or google apps
2010-05-22 15:00 <sharoon> ?
2010-05-22 15:00 <cedk> sharoon: ok, but first the goal is to replace such services
2010-05-22 15:00 <Timitos> cedk: there are cases where such configurations with one server for different domains make the risk to see the email as spam.
2010-05-22 15:01 <sharoon> Timitos: agree on that! i had faced the issue
2010-05-22 15:01 <cedk> Timitos: no, you must configure your domain correctly
2010-05-22 15:01 <sharoon> cedk: especially google treats it as spam
2010-05-22 15:01 <cedk> sharoon: give me the example and I will give you how to deal with it
2010-05-22 15:01 <Timitos> cedk: there a configurations on the net that do not allow this. many small companies will be not able to do these configurations
2010-05-22 15:01 <cedk> sharoon: dig -t TXT
2010-05-22 15:02 <cedk> Timitos: I'm not sure
2010-05-22 15:02 <Timitos> cedk: not every provider allows configration of MX-Records
2010-05-22 15:02 <cedk> Timitos: if they own an domain
2010-05-22 15:02 <paepke> cedk, does that x-reply-to overwrite the "from" in the mail client? i don't think so. it will look disgusting to the recipient.
2010-05-22 15:02 <sharoon> cedk: the issue if we design assuming the companies which are going to use tryton to be this complex using their own mail servers and configuring them for a typical 5-10 user company?
2010-05-22 15:02 <cedk> Timitos: it is not the MX records
2010-05-22 15:03 <cedk> paepke: reply-to will make the reply goes to this address
2010-05-22 15:03 <sharoon> cedk: i guess every company will need people with ur know-how and knowledge to use the system
2010-05-22 15:03 <sharoon> cedk: i guess we should make it as simple as possible
2010-05-22 15:03 <Timitos> cedk: there are also other problems
2010-05-22 15:04 <paepke> cedk, yes, i know how that works, but it will not look like the mail was from the guy is responsible for you. it will be from an automated system. not good.
2010-05-22 15:04 <cedk> sharoon: it will work for almost all configurations
2010-05-22 15:04 <sharoon> cedk: but it needs a genius like u to configure ;)
2010-05-22 15:04 <cedk> sharoon: no
2010-05-22 15:05 <cedk> sharoon: did your internet provide give you a SMTP server ?
2010-05-22 15:05 <cedk> paepke: the best is to setup the FROM with the right addresses, but you talked about a special configuration where the SMTP server will rewrite the FROM
2010-05-22 15:06 <sharoon> cedk: no!
2010-05-22 15:06 <sharoon> i use google apps because it makes life easy and my company everybody uses android!
2010-05-22 15:06 <sharoon> am sure there are many companies out there who do that too
2010-05-22 15:06 <sharoon> no small size business (non IT) company will have such a setup
2010-05-22 15:07 <sharoon> they might already have something like hosted outlook, google apps or something like that
2010-05-22 15:07 <cedk> sharoon: I'm pretty sure the google doesn't override the FROM in SMTP server
2010-05-22 15:07 <sharoon> cedk: you get to send a mail using that user only if u login to using the username and password
2010-05-22 15:08 <cedk> sharoon: yes but you can create a user on google for Tryton
2010-05-22 15:09 <cedk> other thing important: if you want Tryton store account information for all users then you must store password in clear in the database
2010-05-22 15:09 <cedk> this is a really big security issue
2010-05-22 15:09 <cedk> one place with all password of every body
2010-05-22 15:11 <Timitos> i do not think that it is possible to store passwords of all users. but i think it will be needed to define smtp servers by database
2010-05-22 15:12 <cedk> Timitos: why ?
2010-05-22 15:12 <Timitos> cedk: FYI: if you mean SPF. there are also many providers that will not allow any configuration of this. and these are especially the big ones
2010-05-22 15:12 <sharoon> cedk: password access by read should be crapped
2010-05-22 15:13 <sharoon> cedk: password access should be allowed only by browse
2010-05-22 15:13 <cedk> Timitos: dyndns for 15$/year
2010-05-22 15:13 <Timitos> and many small companies are hosting their domains there
2010-05-22 15:13 <cedk> sharoon: this is not the issue
2010-05-22 15:13 <sharoon> cedk: we cant ask users to change email accounts they used for years
2010-05-22 15:13 <sharoon> ?
2010-05-22 15:13 <cedk> sharoon: storing clear text password in database is bad
2010-05-22 15:14 <sharoon> cedk: I agree on that
2010-05-22 15:14 <Timitos> cedk: i do not see how dyndns should solve this issue
2010-05-22 15:14 <paepke> cedk, two other things (have to go for half an hour): sending big mails (like reports, results or pictures) will lead to download the full mail to the client and send it again back to somewhere else. on a slow internet connection this would be horrible for the user.
2010-05-22 15:14 <cedk> Timitos: emails are linked to domain
2010-05-22 15:14 <paepke> cedk, another thing you should think about is email-filtering on server side. like sieve or procmail.
2010-05-22 15:14 <cedk> Timitos: if you transfert your domain to dyndns you will be able to customize dns records
2010-05-22 15:14 <sharoon> cedk: also the idea becomes impossible in future where we talk about hosted web client and mobile client
2010-05-22 15:15 <cedk> paepke: you assume that Tryton server is on internet with a slow connection how could you work on that
2010-05-22 15:15 <Timitos> cedk: yes. but i cannot let our customers wait for 1 year to get a working solution because they cannot transfer their domain because of strict contracts
2010-05-22 15:16 <cedk> paepke: agree on email filtering by will come in other topics
2010-05-22 15:16 <sharoon> cedk: its not a good idea to have too many changes
2010-05-22 15:16 <cedk> Timitos: leave the customer
2010-05-22 15:16 <sharoon> cedk: according to gartner... changes cause 60% failures in information system implementations
2010-05-22 15:16 <cedk> Timitos: you will have always bad stuffs with such customer
2010-05-22 15:16 <sharoon> cedk: every user to organisation will be resistant to change
2010-05-22 15:17 <cedk> sharoon: excactly, my design will change any thing to users bahavior
2010-05-22 15:18 <sharoon> cedk: i dont think its a global solution because more and more users are shifting from desktop based solutions to hosted apps
2010-05-22 15:18 <cedk> Timitos: and I think you can transfert domain but you will still need to pay the previous one for one year
2010-05-22 15:18 <Timitos> cedk: i know a provider where this will be not really possible.
2010-05-22 15:18 <cedk> sharoon: ok, if you give your information to outside and don't want to change how could you get it back
2010-05-22 15:19 <cedk> Timitos: that is a bad provider and should not work with it
2010-05-22 15:19 <Timitos> cedk: but i understand your strategy better now.
2010-05-22 15:19 <sharoon> Ok i think i have a solution to this problem
2010-05-22 15:19 <Timitos> cedk: yes. if i would have known the customers when they did their decision this is clear
2010-05-22 15:19 <sharoon> ACTION One possible solution
2010-05-22 15:20 <Timitos> cedk: but unfortunately there are some other people that do things i would not do
2010-05-22 15:20 <cedk> Timitos: you can do nothing with such customer until he leave his previous IT provider
2010-05-22 15:20 <sharoon> let tryton just like now have the default emailing SMTP feature and the mailbox
2010-05-22 15:20 <sharoon> thats just what we have now
2010-05-22 15:21 <sharoon> but, lets have a separate module where the user can configure his own accounts and the email queue will be overridden by that mdoule
2010-05-22 15:21 <Timitos> cedk: i cannot always wait for the perfect customer ;-) but maybe i can help some to be.
2010-05-22 15:22 <cedk> sharoon: for you google issue, you can still put a postfix on Tryton host, and write transfert rule base on from to relay to google smtp with the right account
2010-05-22 15:22 <sharoon> cedk: Greek & Latin
2010-05-22 15:22 <sharoon> cedk: and we ususally have painful administrators who are third party IT support people who will screw our implementatin for nothing if we say this
2010-05-22 15:22 <cedk> Timitos: yes, but you can not sale some thing that you can not do
2010-05-22 15:23 <sharoon> cedk: i guess tryton should not be a deciding factor for the email service etc
2010-05-22 15:23 <sharoon> cedk: already when there are popular protocols like IMAP/POP3 & SMTP to do anythign we want in email
2010-05-22 15:23 <cedk> sharoon: it is not required to use email with Tryton
2010-05-22 15:23 <Timitos> cedk: only when your concept of tryton is too strict to 'the only right way'
2010-05-22 15:24 <cedk> Timitos: there is always a solution
2010-05-22 15:24 <sharoon> cedk: I think we should assume .... We dont get a text book customer who has done everything right
2010-05-22 15:24 <sharoon> cedk: if he has everything right then he doesnt need us
2010-05-22 15:24 <Timitos> so i pointed out my opinion on this. it is all i can do.
2010-05-22 15:25 <sharoon> cedk: Shall we have a vote on this point
2010-05-22 15:25 <sharoon> ?
2010-05-22 15:25 <cedk> sharoon: if you want but there will be vote on some point
2010-05-22 15:25 <cedk> s/vote/veto/
2010-05-22 15:25 <sharoon> Proposition 1:
2010-05-22 15:25 <cedk> like clear text password storage
2010-05-22 15:26 <sharoon> cedk, whether we store password in a db or python file, it has the same effect according to me
2010-05-22 15:26 <sharoon> somebody who has access to server has both
2010-05-22 15:26 <cedk> sharoon: yes but only for one account not for accounts of every employee
2010-05-22 15:27 <cedk> sharoon: especially the google account where I suppose you also store docs and sheets
2010-05-22 15:27 <sharoon> cedk: if you want to send mail from employee account then username and password MUST be stored somewhere
2010-05-22 15:27 <cedk> sharoon: perhaps also google apps etc.
2010-05-22 15:27 <cedk> sharoon: and I don't want to send email from employee
2010-05-22 15:28 <sharoon> cedk: i think its more of an organisational choice
2010-05-22 15:28 <cedk> sharoon: no employees must send their own emails
2010-05-22 15:28 <Timitos> sharoon: is there no possibility to send emails from employee with authentication of another? like a company account?
2010-05-22 15:28 <sharoon> cedk: thats why organisations have emails for employees! i think we should make it flexible for the company which has their policies
2010-05-22 15:29 <sharoon> cedk: Timitos: its possible
2010-05-22 15:29 <cedk> sharoon: otherwise you have the case where employee receive email answer to email that he doesn't know he sended
2010-05-22 15:29 <sharoon> Timitos: my argument is: the same tradeoff exists if password is stored in DB or py file
2010-05-22 15:29 <sharoon> cedk: in your case where employees dont need emails only configure one account
2010-05-22 15:29 <sharoon> no-reply@tryton.local
2010-05-22 15:30 <sharoon> same tradeoff
2010-05-22 15:30 <sharoon> only one account
2010-05-22 15:30 <sharoon> accessible to all
2010-05-22 15:30 <Timitos> sharoon: yes. but maybe it is not needed to store all accounts
2010-05-22 15:30 <sharoon> Timitos: agree
2010-05-22 15:30 <sharoon> its not needed to store all accounts
2010-05-22 15:30 <cedk> once again, sending email is not linked to email account !!!
2010-05-22 15:31 <sharoon> cedk: IT IS for many accounts like the google apps and hosted exchange
2010-05-22 15:31 <Timitos> cedk: yes. i know. but it dependes on the configuration of the provider. some will reject emails that are authenticated by another account
2010-05-22 15:32 <sharoon> cedk: we should allow user to use what he already has.
2010-05-22 15:32 <cedk> Ok we will never have something that works with all crappy configuration
2010-05-22 15:32 <cedk> and we must not encourage bad design
2010-05-22 15:33 <sharoon> google apps is not bad design (though it is)
2010-05-22 15:33 <sharoon> we cant say google is wrong?
2010-05-22 15:33 <cedk> sharoon: I don't say that
2010-05-22 15:33 <Timitos> cedk: sorry. but a configuration like hosted exchange and google apps should be not seen as crappy. these configurations are fact and we should be able to handle them
2010-05-22 15:33 <cedk> sharoon: it is not required to use smtp of google to send your emails
2010-05-22 15:33 <sharoon> cedk: can you explain?
2010-05-22 15:33 <cedk> Timitos: I don't talk about that
2010-05-22 15:34 <Timitos> cedk: why not?
2010-05-22 15:34 <cedk>
2010-05-22 15:34 <Timitos> cedk: why do you not talk about that?
2010-05-22 15:34 <cedk> Timitos: bad design is domain that you can not customize
2010-05-22 15:35 <cedk> I will make a brief history of email
2010-05-22 15:35 <cedk> SMTP is a protocol that allow server to communicate and exchange emails
2010-05-22 15:36 <Timitos> cedk: but you cannot be always against others. if we will only do it one way there will be many potential customers we will be not able to serve
2010-05-22 15:36 <cedk> any server can communicate with any server
2010-05-22 15:36 <Timitos> cedk: i know smtp. this is not the problem. the problem is how it is used today
2010-05-22 15:36 <cedk> Timitos: it is used the same way
2010-05-22 15:37 <Timitos> cedk: but with some restrictions in many cases
2010-05-22 15:37 <cedk> Timitos: no
2010-05-22 15:37 <Timitos> cedk: and i do not think that it is good not to look on how it is used today
2010-05-22 15:37 <sharoon> cedk: "Modern SMTP servers typically use a client's credentials (authentication) rather than a client's location (IP address), to determine whether it is eligible to relay e-mail."
2010-05-22 15:37 <sharoon> cedk: says wikipedia
2010-05-22 15:38 <cedk> sharoon: that is not the subject
2010-05-22 15:38 <Timitos> cedk: ok. so there no more discussion necessary as you have your point and we will be not able to find a conclusion except yours
2010-05-22 15:38 <cedk> Timitos: no, I think you don't know how emails work
2010-05-22 15:39 <sharoon> cedk: to be frank, i think all my existing customers who are funding the email module needs google apps (and they wont change) and they need sending from company mail accounts from two different databses
2010-05-22 15:39 <sharoon> cedk: so i think i will have to build a separate module to meet that
2010-05-22 15:40 <cedk> sharoon: I already said this is possible with one smtp
2010-05-22 15:40 <sharoon> while the standard parts that need to go into official base may accomodate this design of best practise u propose
2010-05-22 15:40 <Timitos> cedk: i understand the configuration you suggest. the only thing i do not agree is that it will always work.
2010-05-22 15:40 <cedk> Timitos: only if you have access to your domain
2010-05-22 15:40 <cedk> Timitos: which must be something that you own
2010-05-22 15:41 <cedk> Timitos: otherwise you have been steal
2010-05-22 15:41 <Timitos> cedk: yes. but sorry for this. this is for small companies not always the fact because they made mistakes in past.
2010-05-22 15:41 <Timitos> cedk: they own it but they do not have all possibilites of configuration
2010-05-22 15:42 <cedk> Timitos: from the web interface, but I'm pretty sure with a phone call you can have what you want
2010-05-22 15:42 <Timitos> cedk: no. i know that
2010-05-22 15:42 <sharoon> cedk: can u explain how u will handle my case?
2010-05-22 15:42 <cedk> sharoon: setup an smtp server on the Tryton server that will send emails
2010-05-22 15:43 <sharoon> cedk: lol, that doesnt show in the sent mail history or search results of my client's mailbox
2010-05-22 15:44 <sharoon> in google apps
2010-05-22 15:44 <cedk> sharoon: mail history is not set by the smtp server but by the email client
2010-05-22 15:45 <sharoon> cedk: if the mail gets sent through the email account, only then it gets logged in sent mail
2010-05-22 15:46 <Timitos> sharoon: i think you will need to do base modules without the possibility to send throught the employee accounts and to put another module on top to add this possibility.
2010-05-22 15:46 <sharoon> Timitos: +1
2010-05-22 15:46 <sharoon> cedk: i think that's the best design
2010-05-22 15:47 <Timitos> sharoon: the base ones will be part of the tryton framework (i hope so) and the other one will be a custom one
2010-05-22 15:47 <sharoon> tryton will then stick to best practices while still allowing the user to use his config but at the risk
2010-05-22 15:47 <Timitos> sharoon: yes
2010-05-22 15:48 <cedk> sharoon: did you receive the email I send with your email addresses ?
2010-05-22 15:48 <sharoon> cedk: I guess that ok
2010-05-22 15:48 <sharoon> cedk: it went to spam
2010-05-22 15:49 <cedk> sharoon: by the way, as emails are stored in Tryton and Tryton send it, he can put it in the send folder
2010-05-22 15:49 <cedk> sharoon: of course because DNS is not completly well configured
2010-05-22 15:49 <cedk> sharoon: but it is doable
2010-05-22 15:49 <sharoon> cedk: advice me how to block that though
2010-05-22 15:49 <sharoon> ;)
2010-05-22 15:49 <cedk> sharoon: and also it is suspicious to have email with same from and to
2010-05-22 15:50 <cedk> sharoon: ok after the talk
2010-05-22 15:50 <sharoon> ok, next topic
2010-05-22 15:50 <cedk> but the demonstration was that it is possible to send email linked to gmail from other server
2010-05-22 15:51 <cedk> without having the account informations
2010-05-22 15:51 <sharoon> but cedk it gave me this link instead of ur mail
2010-05-22 15:51 <sharoon>
2010-05-22 15:52 <sharoon> ACTION conclusions so far
2010-05-22 15:52 <cedk> sharoon: ok this is because I send it with same from and to
2010-05-22 15:52 <cedk> sharoon: I could do it with an other email addresses if you want
2010-05-22 15:52 <sharoon> ACTION Tryton will have an email queue built into the server to which emails can be pushed with all required header tags
2010-05-22 15:53 <sharoon> ACTION tryton builtin SMTP will push emails from this
2010-05-22 15:53 <cedk> sharoon: not builtin SMTP
2010-05-22 15:53 <sharoon> cedk: ?
2010-05-22 15:53 <sharoon> builtin SMTP client
2010-05-22 15:54 <cedk> sharoon: queue will be empty by using configured smtp server
2010-05-22 15:54 <sharoon> same
2010-05-22 15:54 <sharoon> lingua!
2010-05-22 15:54 <cedk> sharoon: for me builtin SMTP means writing smtp server
2010-05-22 15:54 <sharoon> anyway and a custom module will be implemented for the purpose of custom configs with clear warning of security
2010-05-22 15:55 <sharoon> using the custom module would mean disabling the builtin SMTP "client" in python of tryton and using custom configs to push mails
2010-05-22 15:55 <sharoon> ACTION next topic is templating
2010-05-22 15:56 <cedk> I think we should use genshi
2010-05-22 15:56 <cedk> because already use in relatorio
2010-05-22 15:56 <sharoon> I agree on that because its already a dependency
2010-05-22 15:56 <cedk> so it doesn't bring new dependency
2010-05-22 15:57 <sharoon> but the bigger picture is how to integrate with triggers because templates are what decides the triggers as well
2010-05-22 15:57 <cedk> and if the code is well writen, it will be possible to add other templating with external modules
2010-05-22 15:57 <sharoon> cedk: agree on that
2010-05-22 15:58 <cedk> before talking of trigger, I want to talk about template storage
2010-05-22 15:58 <sharoon> ok
2010-05-22 15:59 <cedk> I think template email must be stored with the same model than email
2010-05-22 15:59 <cedk> because it will allow to design email with the email client
2010-05-22 16:00 <sharoon> cedk: not really sure
2010-05-22 16:00 <sharoon> cedk: because how do we handle reports as attachments
2010-05-22 16:00 <Timitos> cedk: can you explain this a little bit more?
2010-05-22 16:00 <cedk> sharoon: attachments can be added on the fly
2010-05-22 16:01 <sharoon> cedk: in automatic?
2010-05-22 16:01 <sharoon> cedk: when PO is confirmed send automatic mail to x-user
2010-05-22 16:02 <cedk> there is two things:
2010-05-22 16:02 <cedk> - the template
2010-05-22 16:02 <cedk> - the rule
2010-05-22 16:02 <sharoon> cedk: the rule is handled by trigger
2010-05-22 16:03 <cedk> the template is just the email data
2010-05-22 16:03 <cedk> sharoon: why not
2010-05-22 16:04 <cedk> sharoon: ok agree, the module must extend ir.trigger
2010-05-22 16:04 <sharoon> cedk: no
2010-05-22 16:04 <cedk> sharoon: why?
2010-05-22 16:04 <sharoon> the trigger when triggered calls the template render method for the corresponding ID and the mail is rendered for the corresponding active id given by trigger
2010-05-22 16:05 <sharoon> the rendered mail is pushed into the queue and the process is done
2010-05-22 16:05 <cedk> sharoon: yes
2010-05-22 16:06 <sharoon> the render includes
2010-05-22 16:06 <sharoon> - rendering the email id: ro, cc, bcc, subject, mail body
2010-05-22 16:06 <sharoon> - multipart objects - attachments
2010-05-22 16:06 <sharoon> in manual mode the render is done and the create mail is shown to the user
2010-05-22 16:06 <cedk> ACTION still agree
2010-05-22 16:07 <sharoon> so the user can modify the mail...
2010-05-22 16:08 <sharoon> in the list view it should be possible to create multiple emails as well
2010-05-22 16:08 <sharoon> select 5 invoices and action->Send reminder
2010-05-22 16:08 <sharoon> the mails should be generated and pushed to queue
2010-05-22 16:09 <cedk> sharoon: the example is not very good, because an report will do the work
2010-05-22 16:09 -!- tekknokrat(~lila@ has joined #tryton
2010-05-22 16:09 <sharoon> cedk: can you explain
2010-05-22 16:09 <cedk> sharoon: create a report reminder on invoice, and right click on the report button to send as attachment
2010-05-22 16:10 <sharoon> cedk: fine... but the point i am trying to make is the templates have to be a separate model where the values have to be stored
2010-05-22 16:11 <cedk> sharoon: don't understand
2010-05-22 16:11 <cedk> template must store nothing
2010-05-22 16:11 <sharoon> cedk: please explain
2010-05-22 16:11 <cedk> template is a template
2010-05-22 16:11 <cedk> I don't know how to explain what is a template
2010-05-22 16:12 <sharoon> ok let me do that
2010-05-22 16:12 <cedk> so it is an email where some part (define by markup) must be substitued when rendered
2010-05-22 16:13 <cedk> like odt file of report are template to generate odt file
2010-05-22 16:13 <sharoon> a template is some templating engine (genshi) based tool is used to generate the email
2010-05-22 16:13 <sharoon> - for example subject - it could be Your order ${object.reference} has been processed
2010-05-22 16:13 -!- tekknokrat(~lila@ has joined #tryton
2010-05-22 16:13 <sharoon> - example mail body
2010-05-22 16:14 <sharoon> Hello ${ or 'Customer'},
2010-05-22 16:14 <sharoon> We thank you for your order.
2010-05-22 16:14 <sharoon> Thanks
2010-05-22 16:14 <sharoon> ${}
2010-05-22 16:15 <sharoon> so rendering the template will first render these
2010-05-22 16:15 <sharoon> then it will generate the reports that were to be created
2010-05-22 16:15 <sharoon> and add it to the mime/multipart message
2010-05-22 16:15 <sharoon> and the email.message object is passed on to the create method of email queue
2010-05-22 16:16 <cedk> yes
2010-05-22 16:17 <cedk> but what is the reason to not store template as an email
2010-05-22 16:17 <sharoon> it will have lot many more fields than an email would have
2010-05-22 16:18 <sharoon> email will be a subset of template
2010-05-22 16:18 <cedk> sharoon: which one?
2010-05-22 16:19 <sharoon> cedk: example: a field builder based fields, report many2many, allowed users, attached trigeer ets
2010-05-22 16:19 <sharoon> etc
2010-05-22 16:19 <cedk> sharoon: it is on the rule
2010-05-22 16:19 <sharoon> cedk: field builder?
2010-05-22 16:20 <cedk> it is the same desing then for report
2010-05-22 16:20 <cedk> and odt files
2010-05-22 16:20 <sharoon> cedk: kind of
2010-05-22 16:20 <cedk> sharoon: field builder is because you think about writing template in Tryton client, but for me it must be done on email client
2010-05-22 16:21 <sharoon> but with extra fields for to, cc, bcc, subject, reply to etc
2010-05-22 16:21 <cedk> sharoon: from, to, cc, etc are in emails
2010-05-22 16:21 <sharoon> cedk: and how do you do it in email client?
2010-05-22 16:21 <cedk> sharoon: click new email, write it and save it in special folder
2010-05-22 16:22 <sharoon> cedk: thats again on a local desktop
2010-05-22 16:22 <cedk> you will have a real email editor
2010-05-22 16:22 <cedk> sharoon: go on your web email client, click new email, write it and save it in special folder
2010-05-22 16:23 <sharoon> cedk: got u
2010-05-22 16:23 <cedk> it is the same as email folders are in Tryton
2010-05-22 16:23 <sharoon> cedk: and how do you attach it to triggers?
2010-05-22 16:24 <cedk> sharoon: assume that ir.trigger have some more fields added by email template module
2010-05-22 16:24 <cedk> sharoon: so it will have a many2one to an email stored (flagged) as a template
2010-05-22 16:25 <cedk> but I don't know yet if it must be extended or inherited
2010-05-22 16:25 <sharoon> cedk: got it, but it should have one more filter that the trigger model and template model must be same?
2010-05-22 16:25 <cedk> with inherit we will be able to create a custom view
2010-05-22 16:26 <sharoon> cedk: i think inherit is better
2010-05-22 16:26 <sharoon> cedk: i guess inheriting email will also be necessary
2010-05-22 16:26 <cedk> sharoon: why?
2010-05-22 16:26 <sharoon> cedk: normal emails in queue have no model?
2010-05-22 16:27 <sharoon> cedk: no template builder either
2010-05-22 16:27 -!- udono( has joined #tryton
2010-05-22 16:28 <cedk> sharoon: don't understand why you talk about email queue
2010-05-22 16:29 <cedk> model of template will be define on rule
2010-05-22 16:30 <sharoon> there will many templates in the template folder
2010-05-22 16:30 <cedk> ir.trigger inherited -> email.rule with all fields you had in poweremail
2010-05-22 16:30 <cedk> + a many2one -> email
2010-05-22 16:31 <cedk> sharoon: yes, you must choose the one you want
2010-05-22 16:31 <sharoon> fine.. looks good
2010-05-22 16:31 <cedk> perhaps we could create subfolder by email.rule
2010-05-22 16:31 <sharoon> and whats the structure of email.queue?
2010-05-22 16:33 <cedk> params of
2010-05-22 16:34 <sharoon> and how do you record if an email has been sent?
2010-05-22 16:35 <cedk> + state field
2010-05-22 16:35 <cedk> or better active boolean
2010-05-22 16:35 <sharoon> better
2010-05-22 16:35 <sharoon> and how do we relate email.queue to email
2010-05-22 16:36 <cedk> sharoon: we don't
2010-05-22 16:36 <cedk> we should not implement IMAP sending email
2010-05-22 16:37 <sharoon> fine... sounds ok so far
2010-05-22 16:37 <sharoon> ACTION next topic: Email reception
2010-05-22 16:37 <cedk> sharoon: normally, it was legacy support
2010-05-22 16:37 <sharoon> cedk: missed it in the accounts section
2010-05-22 16:38 <cedk> so for me, Tryton must become the storage place of emails
2010-05-22 16:39 <sharoon> cedk: It should be possible to recieve mails, store them in tryton and link them to other objects like attachments
2010-05-22 16:39 <cedk> the best way is to configure the smtp reciever server to store emails in Tryton
2010-05-22 16:39 <cedk> for that a procmail like script is ok
2010-05-22 16:39 <sharoon> cedk: please!!!! dont get on to modifying servers
2010-05-22 16:40 <cedk> I'm speaking of the best practice
2010-05-22 16:40 <sharoon> cedk: for that you have to keep modifying code everytime
2010-05-22 16:40 <sharoon> cedk: best practice : No doubt
2010-05-22 16:40 <sharoon> cedk: usability: big questions
2010-05-22 16:40 <cedk> Tryton should promote best practice
2010-05-22 16:41 <sharoon> cedk: should promote... not constrain
2010-05-22 16:41 <cedk> sharoon: there is no constraint
2010-05-22 16:41 <sharoon> can you explain how it will work with procmail
2010-05-22 16:42 <cedk> sharoon: it is not with procmail but with a python script that does the same job as procmail
2010-05-22 16:42 <sharoon> cedk: thats the same what i said but the script should not be hardcoded
2010-05-22 16:42 <cedk> smtp servers need to have a way to store emails
2010-05-22 16:42 <sharoon> cedk: forget servers, i am talking about fetching emails by POP3 or IMAP
2010-05-22 16:43 <cedk> for POP this will be the same
2010-05-22 16:43 <sharoon> cedk let me explain my idea
2010-05-22 16:43 <cedk> just instead of having postfix calling procmail like script, it will be an other script that fecth email
2010-05-22 16:44 <cedk> for IMAP, I don't see the goals as IMAP by default leave emails on the server which is not what we want as Tryton is the default storage place for email
2010-05-22 16:45 <sharoon> whats the problem in leaving mails in server?
2010-05-22 16:45 <sharoon> i dont understand
2010-05-22 16:45 <cedk> sharoon: duplicated data
2010-05-22 16:45 <sharoon> well IMAP was designed for that purpose
2010-05-22 16:45 <cedk> except if you will write a synchronize script
2010-05-22 16:45 <sharoon> cedk: not needed
2010-05-22 16:46 <sharoon> cedk: IMAP gives read unread info and servers maintain ID of mails
2010-05-22 16:46 <cedk> sharoon: the purpose of IMAP is to leave email on the server side and fetch it on demand
2010-05-22 16:46 <sharoon> cedk: i already implemented this for poweremail and it works. i see no reason it shoudl not work here
2010-05-22 16:47 <cedk> sharoon: synchronisation because if you move emails or read it then you should push back the info to the IMAP server
2010-05-22 16:47 <sharoon> cedk: its possible to do that, say on read
2010-05-22 16:48 <cedk> sharoon: first, you must not set email as readed as soon as the real user did not read it
2010-05-22 16:48 <cedk> sharoon: but it can work if you use IMAP as POP
2010-05-22 16:48 <cedk> sharoon: fetchone and remove/leave it
2010-05-22 16:49 <sharoon> cedk: ok, thats upto the user
2010-05-22 16:49 <sharoon> lets not talk protocols, it more important to first set the reception
2010-05-22 16:49 <sharoon> emails are stored within the email
2010-05-22 16:49 <cedk> so the procmail script will create an email record
2010-05-22 16:49 <sharoon> i dont understand the need of an external procmail script
2010-05-22 16:50 <cedk> because it is postfix that call it
2010-05-22 16:50 <cedk> it is better to have push then pull
2010-05-22 16:51 <sharoon> i dont know, then this will also be an extra addon
2010-05-22 16:51 <sharoon> because hardcoding to some script which you then set as cron in the system environment according to me is extra pain while not needed
2010-05-22 16:52 <sharoon> i dont see a bad practice in fetching mail with the python library
2010-05-22 16:52 <cedk> sharoon: I don't say that
2010-05-22 16:52 <cedk> I said it is better to have push the pull
2010-05-22 16:52 <cedk> so you cron example is a pull design
2010-05-22 16:52 <sharoon> yes
2010-05-22 16:53 <cedk> with postfix it will be a push design because script will be called at email reception
2010-05-22 16:54 <sharoon> why is pull a bad design?
2010-05-22 16:54 <cedk> for POP, I don't know well the protocol so it will perhaps be a pull in a cron
2010-05-22 16:54 <sharoon> with postfix how do you set the usernames password etc
2010-05-22 16:54 <sharoon> thats too much configuration
2010-05-22 16:54 <cedk> for IMAP, you can keep the connection up and server will push you new emails
2010-05-22 16:55 <cedk> sharoon: which username and password?
2010-05-22 16:56 <sharoon> credentials to fetch emails
2010-05-22 16:56 <cedk> sharoon: postfix no credentials
2010-05-22 16:56 <sharoon> google apps?
2010-05-22 16:56 <cedk> sharoon: with POP and IMAP, of course it is required
2010-05-22 16:56 <cedk> sharoon: but you can not do in any otherway except if you can have a master user/password
2010-05-22 16:57 <sharoon> cedk: that is only possible for your kind of ppl... not simple users and organisations
2010-05-22 16:57 <cedk> again here is the best practice, you could write your own module that will pull emails
2010-05-22 16:57 <sharoon> cedk: so that concludes it
2010-05-22 16:57 <sharoon> ACTION legacy support
2010-05-22 16:58 <cedk> sharoon: email object need to have a generic income method that any pull/push code will call to store new emails
2010-05-22 16:58 <cedk> this method just need to get the data of the email
2010-05-22 16:59 -!- eLBati(~elbati@ has joined #tryton
2010-05-22 16:59 <cedk> it will parse the to, cc value to create all the emails and put it into the INBOX
2010-05-22 16:59 <sharoon> cedk: i think email also should have in addition to create a create_from_email where an email/message as received can be passed
2010-05-22 16:59 <sharoon> the function should parse the mail and read it
2010-05-22 16:59 <sharoon> so we stick to the standards
2010-05-22 16:59 <cedk> sharoon: yes that is the income method I told
2010-05-22 17:00 <cedk> but here is the big question:
2010-05-22 17:00 <cedk> how do we store emails with many to or cc
2010-05-22 17:00 <cedk> shall we create one email per addresses or only one email
2010-05-22 17:01 <sharoon> char fields have no limit right?
2010-05-22 17:01 <cedk> yes
2010-05-22 17:01 <sharoon> so no issue
2010-05-22 17:01 <cedk> but I don't see the link with the question
2010-05-22 17:01 <sharoon> collon or comma separated
2010-05-22 17:01 <cedk> sharoon: I think you don't understand the question
2010-05-22 17:02 <sharoon> ACTION absent minded!
2010-05-22 17:02 <sharoon> cedk: please say
2010-05-22 17:02 <sharoon> i missed the point i guess
2010-05-22 17:02 <cedk> you receive an email with many to receipt (you and your colleague)
2010-05-22 17:02 <sharoon> ok
2010-05-22 17:02 <cedk> so how Tryton will stire this email
2010-05-22 17:02 <cedk> one copy per user ?
2010-05-22 17:03 <cedk> or one copy and link it to INBOX of each one
2010-05-22 17:03 <sharoon> if my account is configured to recieve mail i receive one
2010-05-22 17:03 <sharoon> if he has not configured he doesnt receive any
2010-05-22 17:03 <sharoon> if he also has confgured he gets a copy as well
2010-05-22 17:03 <sharoon> so its nothing to do with to, cc & bcc
2010-05-22 17:03 <cedk> sharoon: this is because of your bad design :-) with gmail
2010-05-22 17:04 <cedk> but we can find that we receive duplicate emails
2010-05-22 17:04 <cedk> same copy
2010-05-22 17:05 <cedk> so if we make some rules to link it to party or crm case etc. we will have duplicate email on those records
2010-05-22 17:05 <sharoon> cedk: i told you u guys are genius,but there are not many out there and certainly my customers dont employ them ;)
2010-05-22 17:05 <cedk> and it will not reflect the reality
2010-05-22 17:05 <sharoon> cedk: we wont have personal accounts related to crm
2010-05-22 17:05 <sharoon> cedk: it will be one account like sales@tryton.local that will be there
2010-05-22 17:05 <cedk> sharoon: customer always send with people in cc
2010-05-22 17:06 <cedk> sharoon: to be sure to receive it
2010-05-22 17:06 <sharoon> cedk: but it doesnt generate duplicate records because ny personal mail is not attached to crm
2010-05-22 17:06 <sharoon> cedk: but sure it creates duplicate emails
2010-05-22 17:06 <cedk> sharoon: the goal is to have all communication (emails) of the company in one place
2010-05-22 17:07 <cedk> where we could make data mining
2010-05-22 17:07 <cedk> and so duplicates data will make data mining less efficient
2010-05-22 17:07 <sharoon> cedk: lol, then every account has to be configured with credentials
2010-05-22 17:08 <cedk> so I think the income method should check if the same email was not received
2010-05-22 17:08 <sharoon> cedk: that goes against your initial argument
2010-05-22 17:08 <cedk> sharoon: I don't understand why you talk about credentials
2010-05-22 17:08 <sharoon> cedk: normal users will need pull, not push
2010-05-22 17:09 <cedk> sharoon: normal users doesn't care of pull or push (it is only dev stuffs to keep the server load low)
2010-05-22 17:11 <sharoon> anyway, i cannot implement this with popular mail services
2010-05-22 17:11 <cedk> sharoon: why?
2010-05-22 17:11 <sharoon> which normal customers seem to use
2010-05-22 17:12 <sharoon> its extra mainteinance, and administration costs
2010-05-22 17:12 <sharoon> so i think this remains separate
2010-05-22 17:12 <cedk> sharoon: about what are you talking?
2010-05-22 17:14 <sharoon> cedk: i dont think a script like procmail is easy to maintain + i dont see the overload that will be there in duplicate mails.. some simple de-duplication could be done, but again that could be future releases
2010-05-22 17:14 <sharoon> my first priority is to get something working
2010-05-22 17:14 <sharoon> without big pits even if it is not a text book implementation
2010-05-22 17:15 <cedk> sharoon: procmail, you can go with what you want as at least we have a single point for incoming emails
2010-05-22 17:15 <sharoon> cedk: so i guess all the points have been covered...
2010-05-22 17:15 <sharoon> cedk: its not possible to have legacy support and still maintain it with so many changes
2010-05-22 17:15 <sharoon> so i drop the idea
2010-05-22 17:15 <cedk> sharoon: no for me duplicate emails is very important
2010-05-22 17:16 <sharoon> cedk: but its just part of the create_from_mail... we can improve it after intitial design
2010-05-22 17:16 <cedk> sharoon: I still don't understand what are you dropping?
2010-05-22 17:16 <sharoon> its not a big change anywaty
2010-05-22 17:16 <cedk> sharoon: it is a big change
2010-05-22 17:17 <cedk> sharoon: because from that linked email to folders will depend
2010-05-22 17:17 <cedk> sharoon: and also tracking the state of the email (unread, read, etc.)
2010-05-22 17:17 <sharoon> cedk: i dont think its a priority for a first working release
2010-05-22 17:18 <cedk> if you go in one direction, you could not come back to the other one
2010-05-22 17:18 <sharoon> cedk: i think we keep some basic guidelines so that the basic design does not hinder change
2010-05-22 17:18 <cedk> or the migration script will require too much work than implementing at first place
2010-05-22 17:19 <cedk> sharoon: yes, and we have not yet define the design of email and folders
2010-05-22 17:20 <sharoon> * email.mailbox
2010-05-22 17:20 <sharoon> o name: char
2010-05-22 17:20 <sharoon> o users: many2many email.mailbox-res.user
2010-05-22 17:20 <sharoon> * email.mailbox-res.user
2010-05-22 17:20 <sharoon> o mailbox: many2one email.mailbox
2010-05-22 17:20 <sharoon> o user: many2one res.user
2010-05-22 17:20 <sharoon> o parent: many2one email.mailbox
2010-05-22 17:20 <sharoon> o subscribed: boolean
2010-05-22 17:20 <sharoon> Unique: mailbox, user
2010-05-22 17:20 <sharoon> that was the original design from blueprint
2010-05-22 17:20 <sharoon> i guess that will suffice
2010-05-22 17:20 -!- sharkcz( has joined #tryton
2010-05-22 17:22 <cedk> sharoon: I think it is not correct
2010-05-22 17:23 <sharoon> cedk: please propose
2010-05-22 17:23 <cedk> I think flags must not be on email
2010-05-22 17:24 <cedk> but on the many2many table that link email to mailbox
2010-05-22 17:24 <cedk> like that we can put same email in different mailbox
2010-05-22 17:24 <cedk> of diffrent user
2010-05-22 17:25 <cedk> sharoon: I need to think more
2010-05-22 17:25 <sharoon> ok
2010-05-22 17:25 <sharoon> i think i will follow the changes on wiki
2010-05-22 17:25 <cedk> I will make a proposition the WE
2010-05-22 17:26 <cedk> I need to check all commands of IMAP
2010-05-22 17:26 <cedk> sharoon: I think last topic is the IMAP server
2010-05-22 17:27 <sharoon> i think we can discuss that after the first part is implemented
2010-05-22 17:27 <sharoon> ?
2010-05-22 17:27 <sharoon> is that ok?
2010-05-22 17:27 <cedk> ok
2010-05-22 17:43 -!- eLBati(~elbati@ has joined #tryton
2010-05-22 18:09 <paepke> cedk, sharoon. i know i'm late. may i give you my 2c about that incoming mail?
2010-05-22 18:12 <cedk> paepke: no problem
2010-05-22 18:12 <paepke> i agree with cedk about that incoming mail path. if you pull from a pop/imap server you can use traditional tools like fetchmail which work for several years. if you implement this with python a second time, it will be a hard thing cause of the many different implementations.
2010-05-22 18:14 <paepke> with the pop/imap fetching you have to store the username/passwords for every account you fetch. thats the corresponding security hole which you talk about at the sending email topic. but its a common practise. these username/passwords don't have to be the same like the windows or tryton passwords.
2010-05-22 18:15 <cedk> paepke: yes, but the current design will allow also to have pulling
2010-05-22 18:17 <sharoon> paepke: welcome back
2010-05-22 18:17 <paepke> there should be a message deduplication (store only one message) in tryton. a lot of doubled emails for example mails related to project with a lot of members are floating around. every groupware/email server is looking into that cause of the exploding messages. i'm talking about that servers with a database backend.
2010-05-22 18:18 <paepke> cedk, its ok to have both setups. just wanna give you my experience about pulling.
2010-05-22 18:19 <udono> hi
2010-05-22 18:20 <paepke> another point which is currently not mentioned is the attachment. please allow to store that attachment as a file. and only the message in the database. or only the headers. i missed that discussion.
2010-05-22 18:20 <cedk> sharoon: model design updated on wiki
2010-05-22 18:21 <sharoon> cedk: checking
2010-05-22 18:21 <cedk> paepke: take a look at the model design on wiki
2010-05-22 18:22 <sharoon> cedk: are you retaining the falg design
2010-05-22 18:22 <cedk> I propose to store email without header in the data_path like the attachment (so no duplication) and only keep header in record
2010-05-22 18:22 <paepke> email from data_path means a function where you can store it somewhere? cool design decission
2010-05-22 18:22 <cedk> sharoon: yes, because I move only the duplicate part in the data_path
2010-05-22 18:23 <cedk> paepke: data_path is a way to store file in directory like it is done in proxy cache
2010-05-22 18:23 <cedk> paepke: and it store only once a file
2010-05-22 18:23 <cedk> paepke: because we used digest to name this file
2010-05-22 18:24 <paepke> cedk, good.
2010-05-22 18:24 <sharoon> cedk: sexy design
2010-05-22 18:24 <udono> I read the log, and found a lot of interesting ideas. But some questions remain. Is there a way to support POP before SMTP which is used by cheap email providers? I guess it could be an additional module/script...
2010-05-22 18:24 <cedk> I have let the header on the email record because there is some attributes that are unique even on same emails like "Delivery-To:" and "Originate:"
2010-05-22 18:25 <paepke> cedk, but why not store the headers with the file. my intention is to have the email as it was received by tryton. with the digest we can see that it was not mangled.
2010-05-22 18:25 <cedk> udono: POP and SMTP are different protocol for different purpose
2010-05-22 18:26 <paepke> cedk, pop bevore smtp is a kind of poor mans authentication.
2010-05-22 18:26 <udono> cedk: realy? :-)
2010-05-22 18:27 <cedk> udono: is that POP for AUTH on SMTP ?
2010-05-22 18:27 <udono> cedk: yes,
2010-05-22 18:27 <cedk> udono: not supported by python lib
2010-05-22 18:28 <cedk> paepke: for header, here is a scenario:
2010-05-22 18:28 <cedk> one email is sended to two users of Tryton
2010-05-22 18:28 <cedk> so we want to store it only once (especially if there is big attchment)
2010-05-22 18:29 <cedk> but they will have a different header
2010-05-22 18:29 <cedk> because email server will add "Delivery-To:" to each one with his email addresse
2010-05-22 18:29 <udono> cedk: k
2010-05-22 18:30 <cedk> so the data_path storage will store them as different file
2010-05-22 18:30 <cedk> that is why I store the header in the record and the data content in data_path
2010-05-22 18:30 <cedk> paepke: is it ok for you?
2010-05-22 18:31 <sharoon> cedk: concept of header looks solid as of now
2010-05-22 18:32 <udono> cedk: is the E-Mail storage usable for archiving? That means are all incoming mails stored unchanged forever. Deleting a mail from the users client means 'unlink' the email-resource instead of 'deleting' the resource.
2010-05-22 18:33 <paepke> cedk, i have to think about that delivered too. i'm not sure about.
2010-05-22 18:34 <paepke> udono, cedk: it should be possible to change the link to the email in the future. like that archiving udo is talking about. just copy over to a different, slower storage.
2010-05-22 18:34 <cedk> udono: if we don't delete email records
2010-05-22 18:37 <paepke> i'm just thinking: what about a second imap-mailbox with archived mails. if you delete it in your primary inbox it gets an archive flag and it shows up in your archive inbox. so you can clean your mails and its not a big deal to the server. cron jobs could move the files at night to a secondary storage.
2010-05-22 18:38 <cedk> paepke: I prefer logical delete
2010-05-22 18:40 <paepke> cedk, for example in germany you have to remain all emails which you recieve for 10 years. (well thats totally short, there are exceptions and so on.)
2010-05-22 18:41 <paepke> cedk, but a user wants a clean inbox.
2010-05-22 18:41 <cedk> paepke: logical delete
2010-05-22 18:41 <paepke> how can the user access the mail after that?
2010-05-22 18:41 <cedk> reactive it
2010-05-22 18:41 <paepke> cedk, please explain. maybe i misunderstand.
2010-05-22 18:42 <paepke> cedk, you mean that struck out in the mail client?
2010-05-22 18:43 <cedk> paepke: no it is active field like any where else
2010-05-22 18:44 <udono> paepke: I guess you do this in Tryton, which will be a kind of a control-center of the companies Emails.
2010-05-22 18:47 <paepke> udono, that breaks up the mail managing interface (eg thunderbird)
2010-05-22 18:48 <udono> paepke: why?
2010-05-22 18:48 <paepke> udono, how would you manage it? there has to be an mail client interface in tryton?
2010-05-22 18:49 <paepke> udono, you have to build up sfolderstructure for example to select the mail.
2010-05-22 18:50 <paepke> but ok, you have a great search interface to the mails.
2010-05-22 18:51 <paepke> in my oppinion the mail handling should be one interface - the mail client. for example deleting a mail results in archiving into a second mailbox.
2010-05-22 18:52 <udono> paepke: As far as I understood, a simple and generic interface for e-mails will be provided in Tryton. cedk? sharoon?
2010-05-22 18:55 <paepke> cedk, i have that delivered-to only on my gmail account. every other accout don't us it. youre right. that breaks the single instance storage.
2010-05-22 18:56 <cedk> I have updated the model storage to store almost the complete email without some define custom header
2010-05-22 18:56 <cedk> paepke: I don't think you must handle deleted email from email client
2010-05-22 18:57 <cedk> paepke: it is more like a backup so when user realize that he need a deleted email, he will ask to the admin to restore it
2010-05-22 18:58 <paepke> cedk, yes, like an trash. an important thing. but the user should have the possibility to restore that mail by himself
2010-05-22 18:58 <paepke> cedk, before a cron job gets rid of it after 30 days
2010-05-22 19:00 <paepke> cedk, don't you have an use case for an extra email archive? outside of your mailbox.
2010-05-22 19:00 <paepke> cedk, it would be great to have that without buying an extra email archive appliance.
2010-05-22 19:02 <cedk> paepke: I find email archive unuseful with IMAP
2010-05-22 19:02 <cedk> paepke: it will be something doable with custom module
2010-05-22 19:03 <cedk> again we should build simple module and extend it with other
2010-05-22 19:03 <paepke> cedk, maybe youre right with custom module. its just another big point for a lot of companies.
2010-05-22 19:04 <udono> paepke: since email storage is on file system, you can 'archive' your mails with your file system tools.
2010-05-22 19:04 <paepke> cedk, imap is not an archive. its an protocol.:-). it could be a possible access protocol to an archive.
2010-05-22 19:05 <cedk> paepke: I mean as I use IMAP I don't have all my emails on my PC but only those who I want
2010-05-22 19:05 <paepke> udono, the big point in archiving is to store it in a way where you can not modify it. that could be done with tryton so that the user cannot change it.
2010-05-22 19:06 <cedk> sharoon: is the data model ok for you?
2010-05-22 19:06 <sharoon> cedk: looks ok to me, will get back to you when we are implementing if any issues are there
2010-05-22 19:07 <paepke> cedk, youre an expierienced user. i know not much users which are able to subscribe to certain folders
2010-05-22 19:07 <cedk> sharoon: ok, but try to publish/coderview each modules as soon as possible
2010-05-22 19:08 <sharoon> cedk: fine
2010-05-22 19:09 <cedk> guys don't forget to review triggers
2010-05-22 19:10 <paepke> cedk, i think in a freshly designed email server there should be an archive solution integrated. but thats just my personal thoughts.
2010-05-22 19:11 <paepke> cedk, sharoon: its impressive that you do such a big thing like programming a whole webserver.
2010-05-22 19:11 <paepke> mailserver... :-/
2010-05-22 19:11 <udono> paepke: Data is always changeable. So you need a kind of automated signature of all incoming and outgoing mails to follow changes. I think the Tryton mail storage is not the right place for doing this, because the headers and contents will be changed if I understand correctly. The tryton storage archive is IMHO more useful for data mining.
2010-05-22 19:12 <paepke> udono, the best point to archive an mail is at the incoming smtp-server.
2010-05-22 19:13 <paepke> udono, but at the discussing with integrated polling its necessary to have it.
2010-05-22 19:13 <cedk> udono: the archiving principle of no changeable data is a dream
2010-05-22 19:14 <cedk> and I think the data_path is good enough for archiving
2010-05-22 19:14 <cedk> we will only remove headers that are added by your own email server
2010-05-22 19:14 <paepke> udono, cause of the changeble headers i were asking about the full mail as stored file.
2010-05-22 19:14 <cedk> and nothing about the content
2010-05-22 19:15 <cedk> nor the common headers like Date, Received:, Message-ID:, Subject: etc.
2010-05-22 19:15 <paepke> cedk, the headers are important, too. but you already mentioned it.
2010-05-22 19:15 <cedk> paepke: but not what we will remove
2010-05-22 19:16 <cedk> paepke: because it is something you add to it (with your server)
2010-05-22 19:16 <paepke> cedk, yes. youre totally right.
2010-05-22 19:16 <udono> paepke: The best point to archive Emails afaik for Germany administration is to do it with a proprietary appliance which is directly behind your router or a service on demand.
2010-05-22 19:16 <cedk> and not all email server add those headers
2010-05-22 19:17 <cedk> udono: I'm pretty sure we will do better then that :-)
2010-05-22 19:17 <paepke> cedk, the big and good point is that appending other tags or information to the mail like a future crm module is to have that archived, too. like assigining to a project. so searching on archived/deleted mails would be comfortable
2010-05-22 19:17 <cedk> paepke: we will not alter headers to attch email to records
2010-05-22 19:18 <cedk> paepke: it will be with many2one in database records
2010-05-22 19:18 <paepke> cedk, but inside the database
2010-05-22 19:18 <cedk> paepke: yes
2010-05-22 19:18 <udono> cedk: Just reflecting the conclusion of some Expert talk about Email archiving in Germany in a last year Linux Journal.
2010-05-22 19:18 <paepke> cedk, fully agree
2010-05-22 19:19 <cedk> udono: common behavior to create a market to sale unecessary stuffs
2010-05-22 19:19 <cedk> so I'm leaving
2010-05-22 19:19 <udono> cedk: may be.
2010-05-22 19:19 <cedk> ACTION bbl
2010-05-22 19:23 <paepke> udono, i agree with cedk. but we can discuss that on the ;-)
2010-05-22 19:32 <udono> paepke: I agree with the governmental requirements for Germany.
2010-05-22 19:33 <paepke> udono, jepp
2010-05-22 19:36 <udono> paepke: and as I said, I do not think that Trytons e-mail storage is the right place for archiving mails in order to these requirements... because the requirements are very nation specific.
2010-05-22 20:39 -!- FWiesing( has joined #tryton
2010-05-22 20:51 -!- zodman(~zodman@foresight/developer/zodman) has joined #tryton
2010-05-22 22:16 -!- zodman(~zodman@foresight/developer/zodman) has joined #tryton
2010-05-22 23:03 -!- zodman(~zodman@foresight/developer/zodman) has joined #tryton

Generated by 2.17.3 by Marius Gedminas - find it at!