| chat.freenode.net #tryton log beginning Thu Jan 28 00:00:02 CET 2010 | ||
| 2010-01-28 04:48 -!- rednul_(n=rednul@host-98-127-54-98.bln-mt.client.bresnan.net) has joined #tryton | ||
| 2010-01-28 05:19 -!- yangoon(n=mathiasb@p549F7158.dip.t-dialin.net) has joined #tryton | ||
| 2010-01-28 07:56 -!- enlightx(n=enlightx@static-217-133-61-144.clienti.tiscali.it) has joined #tryton | ||
| 2010-01-28 08:42 -!- bechamel(n=user@host-85-201-159-186.brutele.be) has joined #tryton | ||
| 2010-01-28 08:50 -!- paepke(n=paepke@p4FEB1820.dip0.t-ipconnect.de) has joined #tryton | ||
| 2010-01-28 09:00 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton | ||
| 2010-01-28 09:50 -!- sharoon(n=sharoont@92.26.82.66) has joined #tryton | ||
| 2010-01-28 10:17 -!- udono(n=udono@dynamic-unidsl-85-197-20-29.westend.de) has joined #tryton | ||
| 2010-01-28 10:18 <sharoon> udono: there? | ||
| 2010-01-28 10:19 -!- paepke(n=paepke@p4FEB1820.dip0.t-ipconnect.de) has left #tryton | ||
| 2010-01-28 10:23 -!- paepke(n=paepke@p4FEB1820.dip0.t-ipconnect.de) has joined #tryton | ||
| 2010-01-28 10:24 <udono> sharoon: yes | ||
| 2010-01-28 10:24 <sharoon> The comment: "'=', '!=') is this right?" i found the code in sale | ||
| 2010-01-28 10:26 <udono> sharoon: do you know what it should do? | ||
| 2010-01-28 10:26 <sharoon> check if the key company is in the context disctionary? | ||
| 2010-01-28 10:27 <udono> sharoon: but what does '=', '!=' exactly? | ||
| 2010-01-28 10:27 <sharoon> udono: something like how the lambda function would be written to verify a condition and select a choise | ||
| 2010-01-28 10:28 <sharoon> udono: If(In('company', Eval('context', {})), '=', '!=') returns = if company is there in context | ||
| 2010-01-28 10:28 <sharoon> udono: else it return != | ||
| 2010-01-28 10:28 <sharoon> udono: then it compares to the value of company in the context dictionary | ||
| 2010-01-28 10:29 <sharoon> udono: i think != is there because if requires two parameters? | ||
| 2010-01-28 10:30 <udono> sharoon: ic, it's a search domain, so there is the right operator choosen. Thanks for explanation! | ||
| 2010-01-28 10:32 <sharoon> udono: cheers!! but is there any convention in naming of predefined states constant? | ||
| 2010-01-28 10:32 <sharoon> udono: like LOCK_SOLVED in this case? | ||
| 2010-01-28 10:34 <udono> sharoon: no, I don't think. usually only STATES is used. I just do not understand LOCK_SOLVED. Maybe better LOCK_CLOSED ? | ||
| 2010-01-28 10:35 <sharoon> udono: got you | ||
| 2010-01-28 10:35 <udono> or more clear STATE_LOCK_CLOSED | ||
| 2010-01-28 10:47 <sharoon> udono: 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 suggest | ||
| 2010-01-28 10:47 <bechamel> sharoon: I'm reading it | ||
| 2010-01-28 10:47 <sharoon> bechamel: thanks | ||
| 2010-01-28 10:50 <yangoon> sharoon: /me on the way... | ||
| 2010-01-28 10:50 <sharoon> yangoon: thanks | ||
| 2010-01-28 10:56 <bechamel> sharoon: 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. | ||
| 2010-01-28 10:59 <udono> bechamel: shure about childs vs. children? | ||
| 2010-01-28 11:00 <bechamel> udono: yes yes, childs is wrong, and I probably forgot other stuff, but i was more talking about db design | ||
| 2010-01-28 11:01 <bechamel> udono, sharoon: what I want to say is that the "employees" o2m should be on the team class not on the queue | ||
| 2010-01-28 11:01 <sharoon> bechamel: i get what you mean | ||
| 2010-01-28 11:02 <udono> bechamel: I understand | ||
| 2010-01-28 11:06 <sharoon> bechamel: is there an issue in the trunk with many2many fields? the record doesnt save the many2many value on the first save | ||
| 2010-01-28 11:06 <sharoon> bechamel: the parent record has to be saved and the select the many2many again and save | ||
| 2010-01-28 11:06 <bechamel> sharoon: yes there is a problem on trunk with m2m | ||
| 2010-01-28 11:07 <sharoon> bechamel: any timeline to fix? | ||
| 2010-01-28 11:08 <bechamel> sharoon: I know cedk worked on it yesterday, but I don't know if it's difficult to solve | ||
| 2010-01-28 11:09 <sharoon> bechamel: are you sure it should be an m2m between queue and team or is it m2o | ||
| 2010-01-28 11:09 <sharoon> ? | ||
| 2010-01-28 11:10 <bechamel> sharoon: 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 teams | ||
| 2010-01-28 11:11 <bechamel> sharoon: a m2m is more flexible | ||
| 2010-01-28 11:11 <sharoon> bechamel: i think its better to have m2m | ||
| 2010-01-28 11:11 -!- paepke(n=paepke@p4FEB1820.dip0.t-ipconnect.de) has joined #tryton | ||
| 2010-01-28 11:11 <sharoon> bechamel: but is there any preferred way of defining access to tickets based on queue team in tryton | ||
| 2010-01-28 11:13 <udono> bechamel: 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. | ||
| 2010-01-28 11:14 <bechamel> with rules (ir.rule) you can ensure than only team linked to the queue are able to see the tickets | ||
| 2010-01-28 11:14 <sharoon> udono: consider my company (probably future scenario).... we have a team to support Open ERP, a team to support Tryton, This team is level 1 support | ||
| 2010-01-28 11:15 <sharoon> udono: when its escalated it comes to a special team of senior developers | ||
| 2010-01-28 11:15 <sharoon> udono: so one team of senior developers have two children | ||
| 2010-01-28 11:22 <udono> sharoon: 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... | ||
| 2010-01-28 11:28 -!- paepke_(n=paepke@p4FEB08A6.dip0.t-ipconnect.de) has joined #tryton | ||
| 2010-01-28 11:29 <sharoon> udono: bechamel: can we look at some support system which we can look for a better name? | ||
| 2010-01-28 11:30 <sharoon> udono: bechamel: os ticket uses department http://osticket.com/wiki/Post-Install_Setup_Guide | ||
| 2010-01-28 12:10 <udono> sharoon: http://doc.otrs.org/2.4/en/html/x1006.html here the queue seems only a container for tickets. | ||
| 2010-01-28 12:10 <sharoon> udono: it looks like it serves the same purpose | ||
| 2010-01-28 12:28 <sharoon> bechamel: I updated the schema according to your suggestion :-) | ||
| 2010-01-28 12:36 <bechamel> sharoon: I see that there is a m2m between employee and team, I don't know if it's a good idea | ||
| 2010-01-28 12:39 <sharoon> bechamel: an employee can be in any number of teams | ||
| 2010-01-28 12:40 <sharoon> bechamel: you can take care of support in reports & say even in forms? | ||
| 2010-01-28 12:40 <bechamel> sharoon: yes, is it needed ? because there is already a m2m between team and queues | ||
| 2010-01-28 12:40 <sharoon> bechamel: so you suggest an o2m from team to employee? | ||
| 2010-01-28 12:41 <sharoon> bechamel: but this is really really flexible though | ||
| 2010-01-28 12:42 <bechamel> sharoon: at the end it depends of how the company that will use the module is organised | ||
| 2010-01-28 12:43 <sharoon> bechamel: so using an m2m will fit all sizes right? | ||
| 2010-01-28 12:44 -!- ikks_(n=ikks@190.158.104.59) has joined #tryton | ||
| 2010-01-28 12:48 -!- sharoon(n=sharoont@92.26.82.66) has joined #tryton | ||
| 2010-01-28 12:56 <yangoon> sharoon: I think one team per queue, teams m2m employees | ||
| 2010-01-28 12:56 <yangoon> bechamel: | ||
| 2010-01-28 12:57 <yangoon> I can not imageine the case where I would want several teams work on one queue | ||
| 2010-01-28 12:57 <bechamel> yangoon: and one queue per team ? | ||
| 2010-01-28 12:58 <yangoon> bechamel: no, a team could have to work on different queues | ||
| 2010-01-28 12:58 <bechamel> anyway if the link between team and queue is a o2o then the classes must be merged | ||
| 2010-01-28 12:59 <yangoon> bechamel: that is at least the current state I am reviewing | ||
| 2010-01-28 12:59 <yangoon> but I would separate teams from queues as you proposed | ||
| 2010-01-28 13:02 <bechamel> yangoon: so if you cannot imagine a queue with several teams, do you imagine an employee in different teams like sharoon suggested ? | ||
| 2010-01-28 13:02 <yangoon> yes | ||
| 2010-01-28 13:03 <yangoon> as he said in his example: one employee could be in 1st level of different queues, another only in one queue | ||
| 2010-01-28 13:22 -!- essich(n=essich@p4FCF996B.dip0.t-ipconnect.de) has joined #tryton | ||
| 2010-01-28 13:22 -!- essich(n=essich@p4FCF996B.dip0.t-ipconnect.de) has left #tryton | ||
| 2010-01-28 13:46 <sharoon> cedk: bechamel: I am not able to build an installer for the trunk client | ||
| 2010-01-28 14:00 -!- sharoon(n=sharoont@92.26.82.66) has joined #tryton | ||
| 2010-01-28 14:21 <udono> sharoon: 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. | ||
| 2010-01-28 14:21 <sharoon> udono: the current implementation has m2m to the 3 entities, which is the most unique | ||
| 2010-01-28 14:21 <sharoon> and flexible | ||
| 2010-01-28 14:55 -!- woakas(n=woakas@190.144.69.234) has joined #tryton | ||
| 2010-01-28 15:01 -!- juanfer(n=juanfer@190.144.69.234) has joined #tryton | ||
| 2010-01-28 15:54 <sharoon> hi can somebody pack the trunk client as an installer for me | ||
| 2010-01-28 15:54 <sharoon> not able to do it tryting since yesterday :( | ||
| 2010-01-28 15:56 <sharoon> cedk: bechamel: have you guys recently tried building the client? | ||
| 2010-01-28 15:56 <cedk> sharoon: no and I have no time now | ||
| 2010-01-28 15:56 -!- tekknokrat(n=gthieleb@dslb-092-078-140-078.pools.arcor-ip.net) has joined #tryton | ||
| 2010-01-28 15:57 <sharoon> cedk: can u just tell me what did u install for gtk? | ||
| 2010-01-28 15:58 <cedk> sharoon: it is in the wiki | ||
| 2010-01-28 15:59 <sharoon> cedk: no luck i had tried | ||
| 2010-01-28 16:22 <bechamel> udono, 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 one | ||
| 2010-01-28 16:26 <sharoon> bechamel: 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!!!! | ||
| 2010-01-28 16:27 <bechamel> sharoon: why you don't want to use the stable version ? | ||
| 2010-01-28 16:30 <sharoon> bechamel: because the two modules i wrote has trytond.pyson | ||
| 2010-01-28 16:34 <bechamel> sharoon: and I think the m2m bug of the trunk were introduced before the pyson stuff .. | ||
| 2010-01-28 16:34 <sharoon> bechamel: but pyson doesnt work with stable right? | ||
| 2010-01-28 16:34 <sharoon> bechamel: does packaging normally have these issues | ||
| 2010-01-28 16:34 <bechamel> sharoon: but replace the pyson stuff should be very long | ||
| 2010-01-28 16:35 <sharoon> bechamel: yes | ||
| 2010-01-28 16:35 <bechamel> sharoon: SHOULDN'T be very long ! | ||
| 2010-01-28 16:36 <sharoon> doing that then | ||
| 2010-01-28 16:36 <sharoon> so is it good to work on existing stuff or create a new branch and do ion that? | ||
| 2010-01-28 16:36 <bechamel> sharoon: always better to work on stable, especialy if it's for a customer | ||
| 2010-01-28 16:38 <bechamel> sharoon: a new repo is cleaner imo, but it's up to you | ||
| 2010-01-28 16:38 <sharoon> bechamel: ok, doiing that | ||
| 2010-01-28 16:38 <sharoon> bechamel: one question whats ur policy on merging modules into the modules folder | ||
| 2010-01-28 16:39 <bechamel> sharoon: we don't need merge, each module is one repo | ||
| 2010-01-28 16:40 <sharoon> i asked abt putting it into tryton/modules | ||
| 2010-01-28 16:42 <bechamel> sharoon: you mean in the official release ? | ||
| 2010-01-28 16:45 <bechamel> sharoon: check my second post on this thread http://groups.google.com/group/tryton/browse_thread/thread/71c5fcf2157611c3/7f52b7b33b76c42a?lnk=gst&q=project+organisation#7f52b7b33b76c42a | ||
| 2010-01-28 16:45 <sharoon> yes | ||
| 2010-01-28 16:45 <sharoon> will read | ||
| 2010-01-28 16:45 <sharoon> now moving code to old states expressions | ||
| 2010-01-28 17:09 -!- paepke_(n=paepke@p4FEB08A6.dip0.t-ipconnect.de) has left #tryton | ||
| 2010-01-28 17:25 <yangoon> bechamel: udono sharoon +1, usually I would go for modules support_ticket, support_ticket_history and support_team (including queue) | ||
| 2010-01-28 17:26 -!- tekknokrat(n=gthieleb@dslb-092-078-140-078.pools.arcor-ip.net) has left #tryton | ||
| 2010-01-28 17:30 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton | ||
| 2010-01-28 17:48 -!- sharoon(n=sharoont@92.26.82.66) has joined #tryton | ||
| 2010-01-28 17:55 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton | ||
| 2010-01-28 18:02 -!- enlightx(n=enlightx@static-217-133-61-144.clienti.tiscali.it) has joined #tryton | ||
| 2010-01-28 19:39 -!- sharoon(n=sharoont@92.26.82.66) has left #tryton | ||
| 2010-01-28 19:39 -!- vengfulsquirrel(n=ian@c-69-181-194-95.hsd1.ca.comcast.net) has joined #tryton | ||
| 2010-01-28 20:46 -!- LucaSub1(n=LucaSub@host27-174-dynamic.2-87-r.retail.telecomitalia.it) has joined #tryton | ||
| 2010-01-28 21:17 -!- Timitos(n=timitos@88.217.184.172) has joined #tryton | ||
| 2010-01-28 21:59 -!- paepke(n=paepke@p54A29B3E.dip0.t-ipconnect.de) has joined #tryton |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!