IRC logs of #tryton for Saturday, 2010-08-14 #tryton log beginning Sat Aug 14 00:00:02 CEST 2010
-!- sharoon( has joined #tryton00:50
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton00:50
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton00:53
-!- zodman(~Miranda@ has joined #tryton01:49
-!- zodman(~zodman@foresight/developer/zodman) has joined #tryton03:20
-!- digitalsatori(~tony@ has joined #tryton06:58
-!- digitalsatori(~tony@ has joined #tryton07:31
-!- evernichon( has joined #tryton10:45
-!- evernichon1( has joined #tryton10:55
-!- sharoon( has joined #tryton11:02
-!- sharoon( has left #tryton13:53
-!- sharoon( has joined #tryton13:57
-!- gremly(~gremly@ has joined #tryton16:48
-!- digitalsatori(~tony@ has joined #tryton17:02
-!- woakas( has joined #tryton17:06
-!- FWiesing( has joined #tryton17:24
-!- ikks(~ikks@ has joined #tryton19:21
-!- zodman(~zodman@foresight/developer/zodman) has joined #tryton19:40
cedkis there someone who already test nested extension?19:59
zodmanhere not .. i reading your email cedk20:04
cedkI have uploaded a new version with some more test20:05
cedkI think it is complet now20:05
cedkI'm just wondering if I should add mcommit or not20:05
zodmantry to add all features as you can and release like other apps on github or bitbucket... for getting adepts20:06
zodmani think20:06
cedkzodman: I will put on hg.tryton.org20:07
cedkbut I like to have always a working version in repo20:08
zodmanpassing to other topic20:10
zodmancedk:  the module support tickets you know if someone work on it ?20:11
cedkzodman: which module?20:11
zodmannot a module sorry i mean "blueprint"20:11
cedkzodman: don't know20:13
cedkzodman: I think it is sharoon who wrote it20:14
cedksharoon: ping20:14
sharooncedk: hi20:14
sharooncedk: i tested nested20:14
sharoonzodman: i wrote the blueprint20:16
sharoonzodman: i think the blueprint has to be rewritten20:16
zodmanyou know if someone having code of it ?20:16
zodmanbecause i want develop it for getting learn tryton modules20:16
sharoonzodman: i think i have the code, but never released it because it s not upto tryton standard20:17
sharoonzodman: also, i think a better way to do it would be to extend the project/task (work) module20:17
sharoonzodman: probably cedk could advice on that20:17
sharoonzodman: else you will have to recreate a lot of things20:17
zodmanthe objective for work on support system its for learn ... but thinking now it cause conflicts with ?20:19
zodmanits cause recreate the wheel ?20:20
sharoonzodman: i dont think its reinventing20:20
sharoonzodman: a project management system + support system could be used by a service providing company20:20
sharoonzodman: you could refer to some designs from ticket systems widely available in other platforms20:21
zodmanboth on same tool.20:21
zodmanmmmm, you are right!20:21
sharooncedk: could you comment pls?20:22
cedksharoon: I don't know20:27
sharoonzodman: may be i take some out today to revise the blueprint20:27
cedkI'm not sure ticket system is really like project20:27
cedkmainly because tickets are not "schedulable"20:28
sharooncedk: ok20:28
cedkI was more thinking that it could be link to the email system20:28
sharooncedk: yep20:29
cedkbut not sure20:29
cedkit is perhaps just a module that must be able to convert emails into tickets20:29
cedksharoon: any way, I find the current design in the blueprint a little bit too complex for a starting module20:35
sharooni am editing it right now20:35
zodmanxD excelente!20:36
sharoonzodman: cedk : could you please check if the design makes sense20:45
zodmansharoon:  for getting the ticket i think the best is take 3 types of ticket20:51
zodman2 types: open, closed20:52
zodmanthe open tickets can set a lot of labels20:52
zodmanbut taking it like open20:52
zodmanlabel of ticket type open: New, Accepted,Started20:52
sharoonzodman: the open and closed are taken care in the boolen field closed20:53
sharoonthe other labels are taken care of in status20:53
zodmanlabel of ticket type closed: Fixed,Invalid, NotReproduced...20:53
sharoonzodman: just refresh20:54
zodmanoooooooooooh ok ok ok ...20:54
sharooni had missed one line20:54
sharoonzodman: maybe we could add sort order in status codes, so that HIgh can be on top of the list and very low in the bottom20:55
sharoonzodman: added that also to design20:56
zodmansharoon:  plz add description entry on ticket.20:57
cedksharoon: I think department should not be in base module21:01
sharoonzodman: done, also added certain future improvements21:01
cedkit can be added later by other module21:01
zodmani understand the singleto but when you refer a Configuration (Singleton) its for complete module configuration ?21:03
zodmanon Support Management >> Configuration>Ticket Settings ?21:03
cedksharoon: I think you should not mix status and priority21:04
sharooncedk: do you suggest separate models?21:04
zodmanas the same logic21:04
zodmani think can be hold on same model.21:06
cedksharoon: I think priority is not well represented with a single field21:08
cedkit is a bad concept21:08
cedkwe should be inspired by the GTD21:09
zodmanexist a gnome app for GTD21:09
cedkin fact the priority is a value linked to many thing and in particulary on time21:10
sharooncedk: ok, so can you propose how we do this?21:10
cedksharoon: not yet :-)21:11
cedkbut I pretty sure that it must not be a simple many2one21:11
sharoonACTION brb21:12
cedkas you can see we did not put pripority field on project.work21:13
cedkby the way, I'm thinking that ticket could extend as extend it21:13
cedklike that employee can enter timesheet on it21:14
cedkACTION lunch21:16
sharoonsorry guys back21:23
sharooncedk: i thought of the same thing before21:23
sharooni think it shold be just another model like project.task21:23
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton21:25
zodmanACTION checking project.work21:30
-!- carlos_( has joined #tryton21:35
zodmanon not put priority ... put order sequence...21:48
zodmanwell i start hacking .. and if neccesary  change it ...21:50
cedkzodman: I tried to explain that priority is not static it depends on time22:06
zodmanok ok.22:15
zodmanseen like that way must divide ...22:15
cedkzodman: yes that is why I don't want to have it in the standard module22:18
-!- FWiesing( has joined #tryton22:39
-!- yangoon( has joined #tryton22:42
cedksharoon: ping23:43
sharooncedk: ping accepted :)23:43
cedkI have other comments on ticket system23:44
sharooncedk: i agree with the fact that the ticket is more like the so should be modelled similar to project.task23:44
cedksharoon: ok23:44
cedkit is about the followup23:44
cedkI think we need to have only one model which is ticket23:45
cedkand we track change on it with history23:45
-!- eLBati(~elbati@ has joined #tryton23:45
cedkand indeed user modify it to communicate23:45
sharoonok, got you,23:45
sharoonwhat do we call that text field?23:46
sharoonFollowup itself?23:46
cedksharoon: we should just have some trick for comments because it must be clear when reading ticket23:46
cedksharoon: not sure because followup is more the history itself23:47
sharooncedk: agree23:48
cedksharoon: I think description or note is good23:48
sharooncedk: agree23:48
sharooncedk: i am not clear about what you said about comments23:48
cedksharoon: if we have only ticket models so the history of the comment/description/note field will give use the communication23:49
sharooncedk: agree23:49
cedksharoon: but when you read the ticket to leave a comment then you need to have a cleared field instead of the last comment23:50
cedksharoon: so I think we will need to have some workarround for that but it is implementation detail23:50
sharoonwe could override read method to clear the field if its there23:50
sharoonor make comment a fcuntional field23:51
sharoonthe setter should set the setter field?23:51
cedksharoon: yes we will see at implementation level23:51
sharooncedk: ok23:51
cedksharoon: I think function field will be cleaner23:51
cedksharoon: next step :-)23:52
cedkowner, I don't think it is a good name23:52
sharooncedk: assignee?23:52
cedksharoon: yes: assigned_to23:52
sharooncedk: ok23:52
cedksharoon: but you need one other field which could be named owner that is a m2o to party23:53
sharooncedk: ok23:53
cedksharoon: and it will represent the party who creates the ticket23:53
cedklike that it could be a customer/supplier or employee etc.23:53
sharooncedk: thats cleaner23:54
cedkbut assigneed_to must be m2o to employee23:54
sharoonjust replacing owner wid that!23:54
cedkI don't see the useness of the flag_closed23:54
sharooncedk: we could probably have a different model for ticket status, in which we could tag a state as a end state23:55
sharoonand the flag_closed should be a boolean field which gets the value from the state it is in23:55
sharoonso many states could be end (eg: Fix released, Wont Fix)23:56
cedksharoon: I don't see why you want to have a end state?23:56
sharooncedk: you mean to say that a ticket could go back any day to state 1?23:56
sharooncedk: thats possible too23:56
cedkmost of the time it is just a convention and fixed/wont fix etc. can be reopen23:56
sharooncedk: agree23:57
cedksharoon: yes so what is the usage of this "end state"?23:57
sharooncedk: may be reporting?23:57
sharooncedk: its useless23:57
sharooncedk: removed!23:57
sharooncedk: any idea about priority, i agree it would be cool to have automatically computed priority23:58
cedksharoon: I think it is enough to handle by grouping on state23:58
sharooncedk: (agree on that)23:58

Generated by 2.11.0 by Marius Gedminas - find it at!