IRC logs of #tryton for Tuesday, 2010-11-23 #tryton log beginning Tue Nov 23 00:00:02 CET 2010
-!- pepeu(~manuel@ has joined #tryton00:18
-!- ikks_(~ikks@ has joined #tryton01:24
-!- chrue1( has joined #tryton01:59
-!- sharoon(~sharoon@ has joined #tryton03:09
-!- pepeu(~manuel@ has joined #tryton03:51
-!- sharoon(~sharoon@ has joined #tryton04:19
-!- sharoon(~sharoon@ has joined #tryton05:12
-!- yangoon( has joined #tryton05:18
-!- zodman(~zodman@foresight/developer/zodman) has joined #tryton06:15
-!- vladimir( has joined #tryton08:09
-!- Timitos(~kp@ has joined #tryton08:29
-!- gasbakid(~gasbakid@ has joined #tryton08:41
-!- pjstevns( has joined #tryton08:58
-!- lem0na(~lem0na@ has joined #tryton09:43
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton09:44
-!- sharoon(~sharoon@ has joined #tryton10:05
-!- Red15(~red15@unaffiliated/red15) has joined #tryton10:13
-!- bechamel( has joined #tryton10:39
-!- paepke( has joined #tryton10:49
-!- vincentvdl(~vincent@ has joined #tryton11:30
-!- kingsnake(~tmulder@ has joined #tryton11:31
kingsnakehi, i have a question about the product module11:36
kingsnakewhat is the purpose of Template in relation to Product?11:36
cedkkingsnake: make some kind of declined products11:45
-!- lem0na(~lem0na@ has joined #tryton11:51
kingsnakecedk: What are declined products?11:54
pjstevns@cedk I think you mean 'derived' not 'declined', right?11:54
pjstevns@kingsnake: it's an inheritance pattern used in more places. The Template is a full-fledged11:54
pjstevnsmodel never used in the GUI, but used as a template for other models11:54
pjstevns@kingsnake: hence the _inherits in Product11:55
pjstevns1) use _inherits if you want to create a new model that adapts/extends an existing model, while leaving the original model as-is.11:56
pjstevns2) use _name overloading if you want to modify an existing model.11:56
cedkkingsnake: general example is T-shirt product11:56
cedkkingsnake: you can create one template for a kind of T-shirt and then just create product linked to this template for each size11:57
cedkkingsnake: this allow to share with all the t-shirt some common field value11:58
kingsnakepjstevns: thanks for explaining11:59
kingsnakecedk: That makes sense but i see issues with stock control since product code is a property of product and in stock moves it references product if i'm correct12:00
cedkkingsnake: i don't see issue12:01
-!- vladimir( has joined #tryton12:02
kingsnakecedk: but then what if the xtra-large t-shirt cost more then the small t-shirt - price is in template but they share the same template12:10
pjstevnskingsnake: you misunderstand: they each have their own table and attributes. Only the model-definition is shared, not the tables or rows12:11
cedkkingsnake: then you develop to put the prices on the product and no more on the template12:13
cedkkingsnake: or you create separated products12:13
pjstevnskingsnake: I checked. Scratch my last message12:16
pjstevnstables and rows *are* shared.12:16
sharoonkingsnake: This pattern is commonly used for using variants within your system... if you can make the relationship from product.tempalte to product.product as o2m12:18
sharooni think udono was working on something similar. i dont remember, somebody was asking alst time about this12:20
sharoonHello all, requesting review for email_template
udonosharoon: kingsnake: you find the old product_variant module here: <disclaimer> This module will NEVER install or run with a recent Tryton version and it has never been finished or tested in real life. Bad code ahead. Using this module could damage the whole world, but at least your Database </disclaimer>12:31
-!- sharoon(~sharoon@ has joined #tryton13:00
-!- GasbaKid_(~GasbaKid@ has joined #tryton13:29
-!- GasbaKid(~GasbaKid@ has joined #tryton13:31
-!- gremly(~gremly@ has joined #tryton15:13
-!- trifon( has joined #tryton15:20
-!- zodman(~andres-va@ has joined #tryton16:28
-!- pjstevns( has joined #tryton16:31
-!- pjstevns( has left #tryton16:32
-!- pheller( has joined #tryton16:46
-!- heg( has joined #tryton17:13
-!- heg_( has joined #tryton17:13
sharoonpheller: ping17:29
phellersharoon: hello17:29
-!- pepeu(~manuel@ has joined #tryton17:29
sharoonpheller: i missed your conversation on email17:29
phellersharoon: No problem.  I was only wondering what your plans were for getting email into Tryton...... if you've already written some MDA for the purpose.17:31
sharoonpheller: For mail server to tryton? or Tryton to up?17:31
phellersharoon: mail server -> tryton17:31
sharoonpheller: ah, that has a few issues, and we discussed with cedk sometime back17:32
sharoonpheller: main problem being the security hole17:32
sharoonpheller: we have to store the password of the user in the DB for the mail server17:32
sharoonpheller: dont know if we have any alternative17:32
phellersharoon:  oh, so you are rather pulling mail from some external server (pop, imap) rather than saying "" is delivered to ....?17:33
phellersharoon: back in 15 min, meeting.17:33
sharoonpheller: will wait for you17:34
phellersharoon: back17:46
paepkepheller, 2c from me: there are a lot of programs around, which do exaclty the pull-thing. fetchmail is a great tool and rather major. there are for sure some counterparts on windows.17:46
phellerpaepke: yes, agreed, there are many programs (and also libraries) to pull.17:46
phellerpaepke: it seems the concern is storing the password for the mail account within the tryton database...17:47
sharoonpaepke: pheller: its easy to make the same functionality in tryton and the tryton scheduler is amazing... if we can devise some way like the keychain/keyring we could do it?17:48
paepkepheller, if you use external programs, you don't have the need to store passwords.17:51
paepkesharoon: a good idea with a keyring. another idea would be to use kerberos, but thats a complex setup for a installation.17:53
paepkesharoon, pheller: the last discussion i had here on the channel ends up that storing passwords in a central way is bad. either on fetchmail or in tryton.17:53
phellersharoon, paepke: basically, if the mail is pulled, the password must be stored somewhere in plain-text, even if only temporally.17:54
paepkesharoon, another idea is to provide the password via the .ini on the client in his homedir.17:54
sharoonpaepke: and how do we fetch it from the client?17:55
paepkesharoon, pheller. the bad thing is that the mail-fetching will only happen when the user is online with his client. bad concept.17:55
paepkesharoon, on login the tryton-client could push it through net-rpc.17:56
paepkesharoon, but it excludes the currently non-existing gwt-client17:56
phellerpaepke: I think it better that an MTA be able to deliver to Tryton via some MDA.17:56
phellerthen no passwords at all....17:57
paepkepheller, so like the fetchmail concept.17:57
phellerpaepke: no... more like a user logs into Microsoft exchange and says "forward all my mail to"17:57
paepkesharoon, pheller every supported os has its own keyring management system. that would offload it to the gtk-client. and make it rather complex.17:57
phellerpaepke: mx is some MTA that has a delivery agent that uses, say, proteus to instantiate a mail object for the user......17:58
paepkepheller, very good idea with proteus. like it.17:58
paepkepheller, there are some setups where the user will not have an internal mail-server structure where he can forward mails.17:59
phellerpaepke: then these users are out of luck.  ;-)18:00
sharoonpaepke: +1 like google apps18:00
sharoonudono: ping18:00
udonosharoon: pong18:00
sharoonudono: just got your review, can i explain here?18:01
udonosharoon: yes18:01
phellersharoon: google apps email has forwarding....18:01
phellersharoon: looking at the it in my google apps account prefs right now....18:01
sharoonudono: basically an 'electronic_mail' record is created from 'electronic_mail.template'18:02
paepkepheller, but would you expose your tryton-mail stuff via the internet?18:02
sharoonudono: so template has all fields of an email (which i dint want to duplicate)18:02
sharoonudono: in addition, it has specific settings exclusive to the template like templating language, report to send etc18:02
sharoonudono: which is why the design uses this pattern - do you have anything better in mind?18:03
sharoonpheller: saw that18:03
paepkepheller, sharoon: fetchmail is based on fetching mail via pop/imap and mail-forwarding via smtp. so it looks like there is an internal mail-server which forwards directly.18:03
phellerpaepke: well, the MTA/MDA could have some intelligence -- perhaps only accept mail from certain domains.  Or, maybe the forwarding address isn't ""; maybe it's a UUID  If the UUID doesn't exist, ignore the message.18:04
phellerback again in 1 hour.... meeting.18:04
udonosharoon: for me a template is a 'base' model, which is extended by specification like done in product, account. Your model say that electronic mail is the base, which is extended by a 'template'. Maybe just the word 'template' is misguiding me.18:05
sharoonpaepke: i think what cedk was suggesting was using the twisted libraries for IMAP18:06
paepkepheller, sharoon: if we use a tryton internal fetching, the user can easily change or add informations which mail-accounts should be fetched. a central approach will offload the work to the it-department.18:06
sharoonudono: yeh, i think thats the problem -  the word template is as in templating, not like in product.template i believe18:06
paepkesharoon, twisted to provide an imap-interface to the mails stored inside tryton. imap can also push18:06
sharoonpaepke: IMHO the best approach is tryton fetching the emails, provided we can build a safe interface to save the password18:07
sharoonpaepke: i went through a few popular support ticket systems etc and allof them seem to store passwords in plain text18:07
sharooncedk: ping - need advice18:08
paepkesharoon, on my ticket system i use the push approach via a delivery daemon on the mta-side. its even faster...18:08
udonosharoon: when I wanted to integrate email functionality in an additional module, which class I usually use, electronic_mail or electronic_mail.template?18:08
sharoonudono: can you give an example?18:09
-!- vincentvdl(~vincent@ has left #tryton18:09
paepkesharoon, anyway for sending mails there would be at least a plain text password in the trytond.conf file like for the sql-database access.18:09
udonosharoon: sorry, can not imagine for now18:09
sharoonudono: i think the module is flexible to send/generate mails from any model/object18:10
sharoonudono: it uses ir.triggers to automatically create mails - so even that is solved18:10
sharoonudono: so i cannot imagine another type of extension other than programmatically triggering template rendering to make an email - for example clicking a button sends a reminder etc18:11
sharoonudono: that could be done using ele... template module18:11
udonosharoon: yes, it looks in general very flexible.18:12
sharoonudono: i hope that fulfils half of the email integration agenda for v2.0 :)18:12
sharoonnow we really need a good idea on how MTA/MDA needs to be designed...18:13
udonosharoon: :-) Maybe I do not understand why you separate into electronic_mail or electronic_mail.template? For me both are one model: electronic_mail18:14
udonosharoon: are there many 'real' emails sharing one template?18:15
sharoonudono: i think we could get more feedback on that, one simple reason for this design is that template takes in value for text part, htl part etc, while they are fetched on the fly from the email binary in the electronic_mail model18:16
udonosharoon: but when taking text part into template, you will have some kind of one2one relationship between electronic_mail and electronic_mail.template?18:18
udonoACTION does not mean fields.One2One(...18:18
sharoonudono: its a one2one relationship in effect18:18
udonosharoon: so, why not just put the fields from electronic_mail.template directly into electronic_mail?18:19
paepkesharoon, there comes something to my mind if we fetch via tryton with a provided username/password: Some/a lot of companies have a password changing rule for example every 3 months. that could be additionally anoying to the user that he has to reset the right password.18:20
udonosharoon: ... this will simplify your model.18:20
sharoonudono: makes me think, can somebody else also review and give feedback18:21
sharoonudono: But cedk was particular that it should be possible to store emails even without the tempating feature18:21
sharoonudono: just as an archive for emails, and i think i agree with the idea18:21
sharoonpaepke: agree18:21
-!- jbunting( has joined #tryton18:21
sharoonudono: in such a case we need it as two separate modules... just trying to put in reasons on 'why' it should be current design... subject to debate of course18:23
udonosharoon: Ic, so you can just extend the electronic_mail model from the other module.18:23
paepkesharoon, on the other hand could be that password be the same as using the ldap-module so the same as on login to tryton.18:23
sharoonpaepke: ah, thats an interesting point we need to keep in mind- atleast when designing the API to ensure that ldap configured emails could adapt too18:24
sharoonudono: yep18:25
paepkesharoon, finally we should support both methods. running a scheduler to fetch mails via tryton. and a kind of smtp/imap/whatever gateway to PUSH mails into tryton18:26
sharoonpaepke: I agree, but anyway to directly reduce the impact of the security issue... one could be encoding the password with some kind of encoding?18:28
paepkesharoon, i have no clue. firefox or other mui's would do it somehow. but that only works when the user is logged in. don't think its a good solution to decode the password on server side.18:31
paepkesharoon, like having a hashing string in trytond.conf or by supplying a keyfile on the server.18:32
sharoonpaepke: thats what django does18:32
sharoonpaepke: they have a hashing string which does most of the encoding bits18:33
paepkesharoon, thats why i mentioned it ;-)18:33
sharoonpaepke: :)18:33
-!- paepke( has joined #tryton18:43
paepkesharoon, and they say: CHANGE IT if you get it by source and look that nobody else will get this file.18:43
paepkesharoon, most likely if someone has access to youre database he will have this file.18:44
sharoonpaepke: got you18:47
paepkesharoon, sorry, for a double post. it was still not in the log.18:48
-!- chrue( has joined #tryton19:06
phellerwow, lots of good discussion on how to get emails into Tryton.  I agree that both push and pull methods should be supported.19:08
-!- vladimir(~vladimir@ has joined #tryton19:31
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton19:37
-!- trifon( has joined #tryton19:53
-!- zodman(~andres-va@foresight/developer/zodman) has joined #tryton19:56
-!- enlightx(~enlightx@ has joined #tryton20:19
-!- GasbaKid(~GasbaKid@ has joined #tryton21:00
-!- pheller( has left #tryton21:10
-!- pheller( has joined #tryton21:10
-!- JoePass(~gasbakid@ has joined #tryton21:41
-!- gavinf( has joined #tryton21:41
-!- heg( has joined #tryton22:45
-!- paepke( has left #tryton22:48
-!- heg( has joined #tryton23:29
-!- heg( has joined #tryton23:44

Generated by 2.11.0 by Marius Gedminas - find it at!