IRC logs of #tryton for Thursday, 2010-01-28 #tryton log beginning Thu Jan 28 00:00:02 CET 2010
-!- rednul_( has joined #tryton04:48
-!- yangoon( has joined #tryton05:19
-!- enlightx( has joined #tryton07:56
-!- bechamel( has joined #tryton08:42
-!- paepke( has joined #tryton08:50
-!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton09:00
-!- sharoon(n=sharoont@ has joined #tryton09:50
-!- udono( has joined #tryton10:17
sharoonudono: there?10:18
-!- paepke( has left #tryton10:19
-!- paepke( has joined #tryton10:23
udonosharoon: yes10:24
sharoonThe comment: "'=', '!=') is this right?" i found the code in sale10:24
udonosharoon: do you know what it should do?10:26
sharooncheck if the key company is in the context disctionary?10:26
udonosharoon: but what does '=', '!=' exactly?10:27
sharoonudono: something like how the lambda function would be written to verify a condition and select a choise10:27
sharoonudono: If(In('company', Eval('context', {})), '=', '!=') returns = if company is there in context10:28
sharoonudono: else it return !=10:28
sharoonudono: then it compares to the value of company in the context dictionary10:28
sharoonudono: i think != is there because if requires two parameters?10:29
udonosharoon: ic, it's a search domain, so there is the right operator choosen. Thanks for explanation!10:30
sharoonudono: cheers!! but is there any convention in naming of predefined states constant?10:32
sharoonudono: like LOCK_SOLVED in this case?10:32
udonosharoon: no, I don't think. usually only STATES is used. I just do not understand LOCK_SOLVED. Maybe better LOCK_CLOSED ?10:34
sharoonudono: got you10:35
udonoor more clear STATE_LOCK_CLOSED10:35
sharoonudono: cedk: bechamel: yangoon: could you please review the code for support system again?? There are some cases where we are looking for a better name. Please suggest10:47
bechamelsharoon: I'm reading it10:47
sharoonbechamel: thanks10:47
yangoonsharoon: /me on the way...10:50
sharoonyangoon: thanks10:50
bechamelsharoon: imo a queue shoudld be (name, parent, active, company, childs), a team should be (employees, manager, *_times) with a m2m between them. a new ticket is put on a queue and is only visible by teams linked to the queue and once openned assigned to one of the team member. The escalation boolean is not needed because it can be inferred from the ticket history.10:56
udonobechamel: shure about childs vs. children?10:59
bechameludono: yes yes, childs is wrong, and I probably forgot other stuff, but i was more talking about db design11:00
bechameludono, sharoon: what I want to say is that the "employees" o2m should be on the team class not on the queue11:01
sharoonbechamel: i get what you mean11:01
udonobechamel: I understand11:02
sharoonbechamel: is there an issue in the trunk with many2many fields? the record doesnt save the many2many value on the first save11:06
sharoonbechamel: the parent record has to be saved and the select the many2many again and save11:06
bechamelsharoon: yes there is a problem on trunk with m2m11:06
sharoonbechamel: any timeline to fix?11:07
bechamelsharoon: I know cedk worked on it yesterday, but I don't know if it's difficult to solve11:08
sharoonbechamel: are you sure it should be an m2m between queue and team or is it m2o11:09
bechamelsharoon: no not sure, it depends if you want to allow a team to handle several queue and/or if you want a queue to be seen by several teams11:10
bechamelsharoon: a m2m is more flexible11:11
sharoonbechamel: i think its better to have m2m11:11
-!- paepke( has joined #tryton11:11
sharoonbechamel: but is there any preferred way of defining access to tickets based on queue team in tryton11:11
udonobechamel: sharoon: Is the name 'queue' right for the nested tree model you use with parent and children? What I do not understand is why this queue concept has many children instead of a single child and a single parent, like FIFO LIFO or other queue concepts.11:13
bechamelwith rules (ir.rule) you can ensure than only team linked to the queue are able to see the tickets11:14
sharoonudono: consider my company (probably future scenario).... we have a team to support Open ERP, a team to support Tryton, This team is level 1 support11:14
sharoonudono: when its escalated it comes to a special team of senior developers11:15
sharoonudono: so one team of senior developers have two children11:15
udonosharoon: thanks, your concept I understand, and find it well so far. It is about the name 'queue' is it right for a parent-children relationship? A queue is for me like a tunnel: one start one end. Your concept has one start and many endings. Maybe it is a conflict between Sales and Copmuter Science slang...11:22
-!- paepke_( has joined #tryton11:28
sharoonudono: bechamel: can we look at some support system which we can look for a better name?11:29
sharoonudono: bechamel: os ticket uses department
udonosharoon: here the queue seems only a container for tickets.12:10
sharoonudono: it looks like it serves the same purpose12:10
sharoonbechamel: I updated the schema according to your suggestion :-)12:28
bechamelsharoon: I see that there is a m2m between employee and team, I don't know if it's a good idea12:36
sharoonbechamel: an employee can be in any number of teams12:39
sharoonbechamel: you can take care of support in reports & say even in forms?12:40
bechamelsharoon: yes, is it needed ? because there is already a m2m between team and queues12:40
sharoonbechamel: so you suggest an o2m from team to employee?12:40
sharoonbechamel: but this is really really flexible though12:41
bechamelsharoon: at the end it depends of how the company that will use the module is organised12:42
sharoonbechamel: so using an m2m will fit all sizes right?12:43
-!- ikks_(n=ikks@ has joined #tryton12:44
-!- sharoon(n=sharoont@ has joined #tryton12:48
yangoonsharoon: I think one team per queue, teams m2m employees12:56
yangoonI can not imageine the case where I would want several teams work on one queue12:57
bechamelyangoon: and one queue per team ?12:57
yangoonbechamel: no, a team could have to work on different queues12:58
bechamelanyway if the link between team and queue is a o2o then the classes must be merged12:58
yangoonbechamel: that is at least the current state I am reviewing12:59
yangoonbut I would separate teams from queues as you proposed12:59
bechamelyangoon: so if you cannot imagine a queue with several teams, do you imagine an employee in different teams like sharoon suggested ?13:02
yangoonas he said in his example: one employee could be in 1st level of different queues, another only in one queue13:03
-!- essich( has joined #tryton13:22
-!- essich( has left #tryton13:22
sharooncedk: bechamel: I am not able to build an installer for the trunk client13:46
-!- sharoon(n=sharoont@ has joined #tryton14:00
udonosharoon: bechamel: yangoon: for me the discussion shows, that there are different opinions about the specific implementation of the support ticket module. So I would vote for a generic solution as a base. And additionally modules for the specific implementation of the connections to departments, teams and employees.14:21
sharoonudono: the current implementation has m2m to the 3 entities, which is the most unique14:21
sharoonand flexible14:21
-!- woakas(n=woakas@ has joined #tryton14:55
-!- juanfer(n=juanfer@ has joined #tryton15:01
sharoonhi can somebody pack the trunk client as an installer for me15:54
sharoonnot able to do it tryting since yesterday :(15:54
sharooncedk: bechamel: have you guys recently tried building the client?15:56
cedksharoon: no and I have no time now15:56
-!- tekknokrat( has joined #tryton15:56
sharooncedk: can u just tell me what did u install for gtk?15:57
cedksharoon: it is in the wiki15:58
sharooncedk: no luck i had tried15:59
bechameludono, sharoon, yangoon : about the ticket module, the most generic is a module that define only ticket (which link them to employee, +history), it should be possible to put teams and queues on another one16:22
sharoonbechamel: i am seriously stuck here because i am not able to build an installer. Now i have the installer working but the installed client doesnt work!!!!16:26
bechamelsharoon: why you don't want to use the stable version ?16:27
sharoonbechamel: because the two modules i wrote has trytond.pyson16:30
bechamelsharoon: and I think the m2m bug of the trunk were introduced before the pyson stuff ..16:34
sharoonbechamel: but pyson doesnt work with stable right?16:34
sharoonbechamel: does packaging normally have these issues16:34
bechamelsharoon: but replace the pyson stuff should be very long16:34
sharoonbechamel: yes16:35
bechamelsharoon: SHOULDN'T be very long !16:35
sharoondoing that then16:36
sharoonso is it good to work on existing stuff or create a new branch and do ion that?16:36
bechamelsharoon: always better to work on stable, especialy if it's for a customer16:36
bechamelsharoon: a new repo is cleaner imo, but it's up to you16:38
sharoonbechamel: ok, doiing that16:38
sharoonbechamel: one question whats ur policy on merging modules into the modules folder16:38
bechamelsharoon: we don't need merge, each module is one repo16:39
sharooni asked abt putting it into tryton/modules16:40
bechamelsharoon: you mean in the official release ?16:42
bechamelsharoon: check my second post on this thread
sharoonwill read16:45
sharoonnow moving code to old states expressions16:45
-!- paepke_( has left #tryton17:09
yangoonbechamel: udono sharoon +1, usually I would go for modules support_ticket, support_ticket_history and support_team (including queue)17:25
-!- tekknokrat( has left #tryton17:26
-!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton17:30
-!- sharoon(n=sharoont@ has joined #tryton17:48
-!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton17:55
-!- enlightx( has joined #tryton18:02
-!- sharoon(n=sharoont@ has left #tryton19:39
-!- vengfulsquirrel( has joined #tryton19:39
-!- LucaSub1( has joined #tryton20:46
-!- Timitos(n=timitos@ has joined #tryton21:17
-!- paepke( has joined #tryton21:59

Generated by 2.11.0 by Marius Gedminas - find it at!