| chat.freenode.net #tryton log beginning Mon Jan 25 00:00:02 CET 2010 | ||
| 2010-01-25 01:56 -!- ikks(n=ikks@190.158.102.38) has joined #tryton | ||
| 2010-01-25 05:19 -!- yangoon(n=mathiasb@p549F7CAE.dip.t-dialin.net) has joined #tryton | ||
| 2010-01-25 08:01 -!- paepke(n=paepke@p4FEB18A0.dip0.t-ipconnect.de) has joined #tryton | ||
| 2010-01-25 08:05 -!- Timitos(n=timitos@88.217.184.172) has joined #tryton | ||
| 2010-01-25 08:21 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton | ||
| 2010-01-25 08:23 <CIA-5> C?dric Krier <ced@b2ck.com> default * 4:9b5a69b0c482 party_siret/tests/__init__.py: Fix typo | ||
| 2010-01-25 08:23 <CIA-5> http://hg.tryton.org/1.4/modules/party_siret/rev/9b5a69b0c482 | ||
| 2010-01-25 08:30 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton | ||
| 2010-01-25 09:14 -!- bechamel(n=user@host-85-201-159-186.brutele.be) has joined #tryton | ||
| 2010-01-25 09:16 <CIA-5> C?dric Krier <ced@b2ck.com> default * 87:7ab09e98ca3e calendar/COPYRIGHT: Update COPYRIGHT | ||
| 2010-01-25 09:16 <CIA-5> http://hg.tryton.org/modules/calendar/rev/7ab09e98ca3e | ||
| 2010-01-25 09:16 <CIA-5> C?dric Krier <ced@b2ck.com> default * 88:3e7ff4138117 calendar/calendar.py: | ||
| 2010-01-25 09:16 <CIA-5> Fix recurrence comparison by using the same timezone | ||
| 2010-01-25 09:16 <CIA-5> Remove first the occurences before create/write | ||
| 2010-01-25 09:16 <CIA-5> http://hg.tryton.org/modules/calendar/rev/3e7ff4138117 | ||
| 2010-01-25 09:18 <CIA-5> C?dric Krier <ced@b2ck.com> default * 15:56c90f1648c8 ldap_authentication/COPYRIGHT: Update COPYRIGHT | ||
| 2010-01-25 09:18 <CIA-5> http://hg.tryton.org/modules/ldap_authentication/rev/56c90f1648c8 | ||
| 2010-01-25 09:18 <CIA-5> C?dric Krier <ced@b2ck.com> default * 16:e1807375ed3c ldap_authentication/res.py: Test also password value for empty password | ||
| 2010-01-25 09:18 <CIA-5> http://hg.tryton.org/modules/ldap_authentication/rev/e1807375ed3c | ||
| 2010-01-25 09:21 -!- udono(n=udono@dynamic-unidsl-85-197-24-110.westend.de) has joined #tryton | ||
| 2010-01-25 09:55 <CIA-5> C?dric Krier <ced@b2ck.com> default * 1457:f0e430cd843c tryton/tryton/gui/window/ (win_export.py win_import.py): | ||
| 2010-01-25 09:55 <CIA-5> Fix unselect many rows in import/export dialog for issue1374 | ||
| 2010-01-25 09:55 <CIA-5> (transplanted from b237e5cbcd70fdc67ccec8e136732ab0a86ce39c) | ||
| 2010-01-25 09:55 <CIA-5> http://hg.tryton.org/1.4/tryton/rev/f0e430cd843c | ||
| 2010-01-25 09:55 <CIA-5> C?dric Krier <ced@b2ck.com> default * 1458:8e291db0e808 tryton/tryton/gui/window/view_form/model/field.py: | ||
| 2010-01-25 09:55 <CIA-5> Send signal record-changed to the wrong parent | ||
| 2010-01-25 09:55 <CIA-5> It must be send to the ModelRecord of the field and not to the | ||
| 2010-01-25 09:55 <CIA-5> ModelRecordGroup | ||
| 2010-01-25 09:55 <CIA-5> (transplanted from 9f1d4df6387c368e791623fac586c65abf817070) | ||
| 2010-01-25 09:55 <CIA-5> http://hg.tryton.org/1.4/tryton/rev/8e291db0e808 | ||
| 2010-01-25 09:55 <CIA-5> C?dric Krier <ced@b2ck.com> default * 1459:f91bfdedc9f2 tryton/COPYRIGHT: Update COPYRIGHT | ||
| 2010-01-25 09:55 <CIA-5> http://hg.tryton.org/1.4/tryton/rev/f91bfdedc9f2 | ||
| 2010-01-25 09:57 -!- CIA-5(n=CIA@208.69.182.149) has left #tryton | ||
| 2010-01-25 09:58 <cedk> CIA is now on #tryton-commit | ||
| 2010-01-25 11:14 -!- sharoon(n=sharoont@89.242.11.180) has joined #tryton | ||
| 2010-01-25 11:15 <sharoon> cedk: is there a crm for tryton or anything in plan? | ||
| 2010-01-25 11:15 <sharoon> bechamel: there? | ||
| 2010-01-25 11:15 <bechamel> sharoon: yes | ||
| 2010-01-25 11:16 <sharoon> bechamel: is there a crm for tryton? or atleast in plan/blueprint? | ||
| 2010-01-25 11:16 <bechamel> sharoon: no there are no crm | ||
| 2010-01-25 11:16 <sharoon> bechamel: any plans/blueprints for it? or anybody already working on it? | ||
| 2010-01-25 11:17 <cedk> sharoon: it depends what you name CRM | ||
| 2010-01-25 11:17 <sharoon> cedk: Not the Open ERP 'crm' anyway | ||
| 2010-01-25 11:17 <bechamel> sharoon: atm we are pondering on a "relation" modules that would defines roles and relation betweens parties, and that could be a good building block for a crm | ||
| 2010-01-25 11:18 <cedk> sharoon: there is some modules on http://mercurial.intuxication.org/tryton/ that extends the party model | ||
| 2010-01-25 11:18 <sharoon> cedk: my work for the triggers are progressing, may not be really clean because its my first in tryton | ||
| 2010-01-25 11:18 <sharoon> cedk: where do i push it for review? | ||
| 2010-01-25 11:18 <cedk> sharoon: http://codereview.appspot.com/ | ||
| 2010-01-25 11:19 <sharoon> cedk: thanks | ||
| 2010-01-25 11:19 <bechamel> sharoon: the other step for a good crm is some email automation but this also need some thought | ||
| 2010-01-25 11:19 <cedk> sharoon: http://code.google.com/p/tryton/wiki/HowtoContribute | ||
| 2010-01-25 11:19 <sharoon> bechamel: thanks, and definitely we are planning our work on it. Poweremail for Tryton | ||
| 2010-01-25 11:20 <bechamel> sharoon: I'm gonna put a code snippet on the wiki that shows how to use trytond as a library | ||
| 2010-01-25 11:20 <cedk> bechamel, sharoon: about the email generation, I thought that we would use reports for that | ||
| 2010-01-25 11:20 <sharoon> bechamel: thanks | ||
| 2010-01-25 11:20 <bechamel> sharoon: great | ||
| 2010-01-25 11:20 <cedk> we already have email definition on report action that is used by the client to send report by email | ||
| 2010-01-25 11:21 <sharoon> cedk: check out the blueprint and the doc i sent you last day,, it will be simialr and based on the triggers | ||
| 2010-01-25 11:22 <cedk> sharoon: I check out but I will have some remarks | ||
| 2010-01-25 11:22 <cedk> sharoon: first I think it must be splitted in many modules | ||
| 2010-01-25 11:22 <cedk> sharoon: I think some parts must be linked with the email integration blue print | ||
| 2010-01-25 11:22 <sharoon> sure | ||
| 2010-01-25 11:25 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton | ||
| 2010-01-25 11:25 <cedk> I've got an X crash so I did not see any message since my last one | ||
| 2010-01-25 11:27 -!- paepke_(n=paepke@p4FEB14FD.dip0.t-ipconnect.de) has joined #tryton | ||
| 2010-01-25 11:28 <cedk> sharoon: I also think that if we have an IMAP server, we could use email writen in the email client as template for emails | ||
| 2010-01-25 11:29 <sharoon> cedk: agree | ||
| 2010-01-25 11:29 <sharoon> cedk: we could use templating languages like django or even mako | ||
| 2010-01-25 11:29 <cedk> sharoon: we already have relatorio | ||
| 2010-01-25 11:29 <sharoon> cedk: i'd prefer to use that for tryton anyway | ||
| 2010-01-25 11:29 <cedk> sharoon: I think we must use only one for the coherence | ||
| 2010-01-25 12:04 -!- sharoon(n=sharoont@89.242.11.180) has joined #tryton | ||
| 2010-01-25 12:06 <bechamel> cedk, sharoon: http://code.google.com/p/tryton/wiki/HowToUseTrytondAsAModule | ||
| 2010-01-25 12:26 <Timitos> cedk: i think i found a lack of information in account module. | ||
| 2010-01-25 12:27 <Timitos> cedk: on the TaxLines of account.move there are only tax codes but not the tax where the code does come from | ||
| 2010-01-25 12:28 <Timitos> cedk: i think it would be good to save also the tax there | ||
| 2010-01-25 12:42 <cedk> Timitos: why not | ||
| 2010-01-25 12:42 <Timitos> cedk: ok. i will provide a patch | ||
| 2010-01-25 12:44 <Timitos> cedk: another point. it would be good when the tax codes could become description field like the taxes because the original description of a tax code could be very long and for the tree a short name would be better. what do you think about? | ||
| 2010-01-25 12:45 <cedk> Timitos: set code as _rec_name | ||
| 2010-01-25 12:48 <Timitos> cedk: but a code is not a name. here in germany we have a real code which is a number. but this is not helpful for the tree view. the real name of the code is too long. | ||
| 2010-01-25 12:49 <Timitos> cedk: an alternative solution could be a text field for a note. would be ok for me too | ||
| 2010-01-25 12:49 <cedk> Timitos: I don't understand what you want to put in | ||
| 2010-01-25 12:50 <Timitos> cedk: i want to put a long description in a second char or text filed on tax code. this way i can put a shorter name on the name field of the tax code to make the tree view more readable | ||
| 2010-01-25 12:51 <cedk> Timitos: so ok | ||
| 2010-01-25 12:51 <cedk> Timitos: you can add a test field on account.tax.code | ||
| 2010-01-25 12:52 <Timitos> cedk: ok. great | ||
| 2010-01-25 12:54 <Timitos> cedk: 3rd point. when the government changes tax rules we will need a solution to set a date range on tax rules. | ||
| 2010-01-25 12:54 <Timitos> cedk: i think it would be good to add two date fields valid_from and valid_to to the tax rule lines | ||
| 2010-01-25 12:54 <cedk> Timitos: in a separate module | ||
| 2010-01-25 12:55 <Timitos> cedk: ok | ||
| 2010-01-25 12:57 <Timitos> cedk: thx for your time. | ||
| 2010-01-25 14:14 -!- sharoon(n=sharoont@89.242.11.180) has joined #tryton | ||
| 2010-01-25 14:20 -!- woakas(n=woakas@190.144.69.234) has joined #tryton | ||
| 2010-01-25 14:22 -!- cedric_b(n=cedric@ANantes-158-1-25-60.w86-195.abo.wanadoo.fr) has joined #tryton | ||
| 2010-01-25 15:35 -!- yangoon(n=mathiasb@p549F31F7.dip.t-dialin.net) has joined #tryton | ||
| 2010-01-25 16:00 -!- juanfer(n=juanfer@190.144.69.234) has joined #tryton | ||
| 2010-01-25 16:13 <sharoon> cedk: there? | ||
| 2010-01-25 16:17 -!- sharoon1(n=sharoont@92.26.82.66) has joined #tryton | ||
| 2010-01-25 16:20 <cedk> sharoon: yes | ||
| 2010-01-25 16:42 -!- sharoon(n=sharoont@92.26.82.66) has joined #tryton | ||
| 2010-01-25 16:53 <sharoon> cedk: do we have a calendar view? | ||
| 2010-01-25 16:56 <cedk> sharoon: no | ||
| 2010-01-25 16:57 <cedk> sharoon: we use CalDAV | ||
| 2010-01-25 16:57 <sharoon> cedk: any tutorial for caldav? | ||
| 2010-01-25 17:02 <cedk> sharoon: http://code.google.com/p/tryton/wiki/HowtoUsingCalendarsWithCalDAV | ||
| 2010-01-25 17:04 <sharoon> cedk: http://code.google.com/p/tryton/wiki/CRM | ||
| 2010-01-25 17:05 <cedk> sharoon: I see, don't forget to put it in the TOC | ||
| 2010-01-25 17:06 <cedk> sharoon: I'm not yet sure that leads are a parties | ||
| 2010-01-25 17:08 <sharoon> cedk: any alternate suggestions? | ||
| 2010-01-25 17:08 <cedk> sharoon: Try to put comment in commit | ||
| 2010-01-25 17:08 <sharoon> cedk: Sure | ||
| 2010-01-25 17:09 <cedk> sharoon: I don't remeber where I saw that, but they was saying that two salers could have the same party as leads | ||
| 2010-01-25 17:10 <cedk> sharoon: so leads could be a Model which is linked to a Party | ||
| 2010-01-25 17:11 <sharoon> cedk: but the problem with that is you are going to have everything replicated for that model and you will have unnecessary complication with the history? for example you can have a meeting/todo for a lead | ||
| 2010-01-25 17:12 <sharoon> cedk: so using the same model parties will ensure that we use a single point of entry? any suggestions on that? | ||
| 2010-01-25 17:13 <bechamel> cedk, sharoon: imho, crm is a matter of relations: a lead is a relation between two parties (the customer and the salers) | ||
| 2010-01-25 17:14 <cedk> leads is even a step before a sale | ||
| 2010-01-25 17:15 <sharoon> cedk: bechamel: This i think is the workflow: | ||
| 2010-01-25 17:15 <sharoon> First time sale to an unknown person: Lead | ||
| 2010-01-25 17:15 <sharoon> not sale, say an enquiry | ||
| 2010-01-25 17:15 <cedk> sharoon: I don't think it will complicate the structure to separate leads and party | ||
| 2010-01-25 17:15 <sharoon> cedk: so events generated for a lead could be linked to the party? | ||
| 2010-01-25 17:16 <cedk> sharoon: why not | ||
| 2010-01-25 17:16 <sharoon> cedk: can you alter the blueprint accordingly? | ||
| 2010-01-25 17:16 <bechamel> cedk: when you say separate lead and party, you means completly new module, or you mean lead 'extend' (inherit) party ? | ||
| 2010-01-25 17:17 <cedk> sharoon: wait we are thinking | ||
| 2010-01-25 17:17 <cedk> bechamel: a relation many2one between lead and party | ||
| 2010-01-25 17:19 <bechamel> cedk: yes, but will be like employee ? (which is also a m2o to party in a way) | ||
| 2010-01-25 17:20 <cedk> bechamel: yes but with a unique constraint that make it a o2o | ||
| 2010-01-25 17:20 <cedk> I think it was on vTiger or SugarCRM | ||
| 2010-01-25 17:20 <sharoon> cedk: i think that sounds good | ||
| 2010-01-25 17:20 <cedk> I'm checking | ||
| 2010-01-25 17:21 <sharoon> cedk: sugar is o2o lead:opportunity o2o account | ||
| 2010-01-25 17:21 <cedk> for info, I use click2try.com | ||
| 2010-01-25 17:28 <cedk> sharoon: in sugarcrm an account can have many leads | ||
| 2010-01-25 17:28 <cedk> sharoon: and I think account is party in Tryton | ||
| 2010-01-25 17:28 <sharoon> cedk: account == party is right | ||
| 2010-01-25 17:30 -!- sharoon(n=sharoont@92.26.82.66) has joined #tryton | ||
| 2010-01-25 17:31 -!- sharoon(n=sharoont@92.26.82.66) has joined #tryton | ||
| 2010-01-25 17:31 <sharoon> cedk: i hope i dint miss any messages | ||
| 2010-01-25 17:31 <cedk> sharoon: no waiting your comeback | ||
| 2010-01-25 17:32 <sharoon> cedk: :-) i think account=party is good| and we can inherit the party object to create a lead | ||
| 2010-01-25 17:32 <cedk> sharoon: I think a party can have many leads | ||
| 2010-01-25 17:32 <sharoon> cedk: agree | ||
| 2010-01-25 17:32 <cedk> sharoon: so you can not inherit party | ||
| 2010-01-25 17:33 <sharoon> cedk: so the object has to be built | ||
| 2010-01-25 17:33 <cedk> sharoon: yes | ||
| 2010-01-25 17:34 <sharoon> cedk: Fields??? Name, Address(O2M) | ||
| 2010-01-25 17:35 <sharoon> cedk: and when do we convert it to opportunity? | ||
| 2010-01-25 17:35 <cedk> per example, a company could have two business core: sotfware and hardware. So it can have a leads for software vendor with a company and an other one for hardware | ||
| 2010-01-25 17:36 <bechamel> sharoon: what do you call opportunity ? | ||
| 2010-01-25 17:37 <cedk> sharoon: does it need to be converted into opportunity? | ||
| 2010-01-25 17:37 <cedk> sharoon: why not just a state | ||
| 2010-01-25 17:37 <sharoon> cedk, bechamel: that was my original idea, states in party | ||
| 2010-01-25 17:38 <cedk> sharoon: but I think final step of a lead is a sale not a party | ||
| 2010-01-25 17:38 <bechamel> the state will be on the lead | ||
| 2010-01-25 17:39 <bechamel> for me one should have to create first a party then add one or several leads on it (likes addresses are created on the party) | ||
| 2010-01-25 17:39 <sharoon> cedk: bechamel: thats one way of taking things> Have parties alone and then Leads, Opportunities are real business opportunities? | ||
| 2010-01-25 17:43 <sharoon> cedk: bechamel: but when a party has just leads and no real business done, we should not have it clogging everywhere | ||
| 2010-01-25 17:43 <sharoon> businesses might have thousands of leads but just a few parties or in SF terms accounts | ||
| 2010-01-25 17:44 <Timitos> i also think that we should see lead and opportunity as an object that is different from a party. for me a the lead object must have a many2one to party.party | ||
| 2010-01-25 17:45 <cedk> sharoon: and what is the problem to have thousands of parties? | ||
| 2010-01-25 17:45 <bechamel> sharoon: it's always possible to put active false on the party if the lead is not successfull | ||
| 2010-01-25 17:45 -!- Timitos(n=timitos@88.217.184.172) has left #tryton | ||
| 2010-01-25 17:45 <sharoon> cedk: all of them will appear when a sale order is cleated | ||
| 2010-01-25 17:45 <cedk> sharoon: when you make a sale or a purchase, you know the party and you type his name | ||
| 2010-01-25 17:45 <sharoon> bechamel: cedk: i like that idea | ||
| 2010-01-25 17:45 <cedk> sharoon: if you sale to someone, you must find it | ||
| 2010-01-25 17:45 -!- Timitos(n=timitos@88.217.184.172) has joined #tryton | ||
| 2010-01-25 17:46 <cedk> sharoon: even if it is not yet a customer, it will become | ||
| 2010-01-25 17:46 <cedk> bechamel: bad idea, this is the best way to have duplicate parties | ||
| 2010-01-25 17:47 <Timitos> sharoon: there is already the possibility to view all parties that are associated with sales. why not do something like this for leads | ||
| 2010-01-25 17:47 <bechamel> cedk: yes I wrote to fast | ||
| 2010-01-25 17:48 -!- essich(n=essich@p4FCF9920.dip0.t-ipconnect.de) has joined #tryton | ||
| 2010-01-25 17:48 <cedk> bechamel: I think for sale we must never filter the parties, it could be done on purchase but this will be done by product-supplier links | ||
| 2010-01-25 17:48 -!- essich(n=essich@p4FCF9920.dip0.t-ipconnect.de) has left #tryton | ||
| 2010-01-25 17:49 <sharoon> cedk: bechamel: Timitos: so can we summarize? | ||
| 2010-01-25 17:50 <cedk> sharoon: leads and opportunities are the same model | ||
| 2010-01-25 17:50 <cedk> sharoon: they are linked to parties | ||
| 2010-01-25 17:50 <sharoon> cedk: OK | ||
| 2010-01-25 17:51 <cedk> sharoon: and can be converted into sales | ||
| 2010-01-25 17:51 <bechamel> cedk: this is new ^ | ||
| 2010-01-25 17:51 <cedk> in fact I think leads == oppotunity with 0 probavility | ||
| 2010-01-25 17:51 <sharoon> cedk: agreed | ||
| 2010-01-25 17:51 <cedk> bechamel: no, I said lead is a step before sale | ||
| 2010-01-25 17:52 <Timitos> cedk: +1 | ||
| 2010-01-25 17:52 <cedk> s/probavility/probability | ||
| 2010-01-25 17:52 <bechamel> ACTION was about to say "so there need a relation between lead and product (or sale lines) ?" | ||
| 2010-01-25 17:52 <cedk> but we must define what are the minimal required fields on lead/opportun. | ||
| 2010-01-25 17:53 <sharoon> cedk +1 | ||
| 2010-01-25 17:53 <cedk> bechamel: don't know, at least product*s* if one | ||
| 2010-01-25 17:54 <sharoon> bechamel: cedk: Product may bot even be finalised when its in lead stage | ||
| 2010-01-25 17:55 <sharoon> How about a Subject, Detail in lead stage | ||
| 2010-01-25 17:55 <bechamel> cedk: it's not bad to put product (or sale lines), because (from sugar) there is also an "opportunity amount" on the lead | ||
| 2010-01-25 17:56 <bechamel> .. but maybe on another module | ||
| 2010-01-25 17:56 <sharoon> bechamel: true its opportunity amount, when in opportunity we need to have it | ||
| 2010-01-25 17:56 <sharoon> bechamel: lead is a pointless state | ||
| 2010-01-25 17:56 <cedk> bechamel: I don't say it is bad, I said it must be lines with product and not only one product | ||
| 2010-01-25 17:57 <cedk> sharoon: I think we even don't need of a state field, because it could be deduced about the information we had | ||
| 2010-01-25 17:58 <bechamel> cedk: like ? | ||
| 2010-01-25 17:58 <sharoon> bechamel: cedk: how?? can you explain... because in future we might need a pipeline of stages | ||
| 2010-01-25 17:58 <sharoon> say x as leads, y as opportunities | ||
| 2010-01-25 17:59 <cedk> sharoon: it can be, if we have an amount then it is an opportunity | ||
| 2010-01-25 18:00 <cedk> sharoon: or it could be any other criteria | ||
| 2010-01-25 18:00 <sharoon> cedk: or even probability of winning | ||
| 2010-01-25 18:00 <sharoon> cedk: zero probability or unknown = leads | ||
| 2010-01-25 18:01 <sharoon> any opinions? | ||
| 2010-01-25 18:02 <bechamel> maybe "lead" and "opportunity" are too specialized, maybe one need a more generic word that encompass both | ||
| 2010-01-25 18:02 <sharoon> bechamel: but every CRM has these words | ||
| 2010-01-25 18:03 <Timitos> sharoon: i think we will need a field proability like cedk said. it can be a percentage | ||
| 2010-01-25 18:03 <bechamel> sharoon: we like to nitpick on this chan :) | ||
| 2010-01-25 18:03 <sharoon> Timitos: +1 I agree... Percentage 0:Lead, else: opportunity is the question now :-) | ||
| 2010-01-25 18:03 <cedk> ACTION bbl | ||
| 2010-01-25 18:04 <bechamel> are there other "states" than lead and opportunity ? | ||
| 2010-01-25 18:04 <Timitos> sharoon: i think that the amount and the percentage are different fields | ||
| 2010-01-25 18:05 <sharoon> bechamel: nope, not seen in any CRM so far | ||
| 2010-01-25 18:05 <Timitos> sharoon: bechamel: maybe 'lost' ? or 'canceled' | ||
| 2010-01-25 18:05 <sharoon> Timitos: if we design this way then yes | ||
| 2010-01-25 18:07 <sharoon> freenode | ||
| 2010-01-25 18:10 <sharoon> till now: http://www.tryton.org/~irclog/latest.log.html | ||
| 2010-01-25 18:11 <sharoon> my chat client is crazy i guess!!!! it pasted to all windows!!!!! | ||
| 2010-01-25 18:12 <sharoon> cedk: so how do we go abt this: (Party->Link to Leads/Opportunities), (Leads/Opportunities), () | ||
| 2010-01-25 18:12 <sharoon> ? | ||
| 2010-01-25 18:13 <sharoon> cedk: bechamel: Timitos: <<PING>> | ||
| 2010-01-25 18:14 <Timitos> sharoon: the relation of lead/opportunity to party is like the releation of sale.sale to party | ||
| 2010-01-25 18:14 <bechamel> sharoon: a lead contains: title, description, O2M to party, a selection (lead, 0%, 20%, .., Confirmed, cancelled) and optionaly a list of product and quantities | ||
| 2010-01-25 18:15 <sharoon> bechamel: can you confirm: is it O2M party or M2o? | ||
| 2010-01-25 18:16 <sharoon> Timitos: yes i believe... it depends on this answer though :-) | ||
| 2010-01-25 18:16 <Timitos> sharoon: i think it is M2O | ||
| 2010-01-25 18:16 <bechamel> sharoon: sorry M2O to party (so the foreign key is on the lead table) | ||
| 2010-01-25 18:16 <Timitos> bechamel: +1 | ||
| 2010-01-25 18:17 <sharoon> bechamel: Timitos: cedk: i think its ok +1 | ||
| 2010-01-25 18:17 <bechamel> sharoon: maybe an "amount" field is also needed | ||
| 2010-01-25 18:18 <bechamel> Timitos: ^ | ||
| 2010-01-25 18:19 <Timitos> bechamel: yes | ||
| 2010-01-25 18:19 <sharoon> bechamel: Amount as a function of sum of product * qty * rate? | ||
| 2010-01-25 18:19 <sharoon> bechamel: or arbitary amount? | ||
| 2010-01-25 18:21 <bechamel> we can start with a simple field, and put the product-quantity list on another modules (with an on_change that update the amount, or with a function field that hide the firt one) | ||
| 2010-01-25 18:21 -!- varun_openlabs(n=VARUN@117.197.50.198) has joined #tryton | ||
| 2010-01-25 18:22 <bechamel> Timitos: sharoon: if we put a list of product-qty we must also add a wizard that automate sale creation | ||
| 2010-01-25 18:22 <sharoon> bechamel: so lets keep it simple | ||
| 2010-01-25 18:23 <bechamel> sharoon: yes, it's better to create simple module that are easy to extend after | ||
| 2010-01-25 18:23 <sharoon> bechamel: +1 | ||
| 2010-01-25 18:23 <sharoon> bechamel: updating the CRM wiki with this update. | ||
| 2010-01-25 18:24 <bechamel> sharoon: ok | ||
| 2010-01-25 18:25 <Timitos> bechamel: +1 for wizard. i also agree to start without a product-qty-list as we can add it later in the process easy. with a module or within the generic module | ||
| 2010-01-25 18:26 <sharoon> Timitos: i think it was, have the list of products & quantities, but leave the amount disconnected | ||
| 2010-01-25 18:26 <bechamel> Timitos: yes, looking at sugar crm I also see a 'Campaign' M2O but it can also be added later | ||
| 2010-01-25 18:27 <Timitos> sharoon: maybe you should really add the list of products and quantities with another module | ||
| 2010-01-25 18:28 <Timitos> bechamel: yes. this is another topic. this is campain management. not needed in the first module | ||
| 2010-01-25 18:32 <sharoon> bechamel: cedk: Timitos: varun_openlabs: http://code.google.com/p/tryton/wiki/CRM | ||
| 2010-01-25 18:34 <bechamel> sharoon: maybe add '...' after '0%,20%,' to show that one can select other percentages | ||
| 2010-01-25 18:35 <sharoon> bechamel: agree, changing | ||
| 2010-01-25 18:36 <bechamel> sharoon: about history: I see two other solutions: | ||
| 2010-01-25 18:36 <Timitos> sharoon: why not using the history function of tryton? | ||
| 2010-01-25 18:36 <Timitos> bechamel: :-) | ||
| 2010-01-25 18:36 <sharoon> bechamel: True! | ||
| 2010-01-25 18:36 <bechamel> sharoon: 1) use history feature of the kernel | ||
| 2010-01-25 18:36 <sharoon> bechamel: Timitos: +1 | ||
| 2010-01-25 18:36 <sharoon> I love tryton | ||
| 2010-01-25 18:37 <sharoon> :-D | ||
| 2010-01-25 18:37 <bechamel> sharoon: 2) drop the selection field and create a opportunity.state model with fields: date, state (lead, 0%, ...), comment | ||
| 2010-01-25 18:37 <sharoon> bechamel: can you edit it? anyway i havent used the history feature so far | ||
| 2010-01-25 18:37 <Timitos> sharoon: for me the stage field is a mix of two fields. the probability and the status. | ||
| 2010-01-25 18:37 <sharoon> bechamel: agree | ||
| 2010-01-25 18:38 <Timitos> the status: (lead, opportunity, confirmed, canceled) | ||
| 2010-01-25 18:38 <Timitos> the propability: a percentage value | ||
| 2010-01-25 18:38 <bechamel> Timitos: yes this is the point, they are mixed on purpose | ||
| 2010-01-25 18:39 <bechamel> Timitos: because they are not really orthogonal | ||
| 2010-01-25 18:40 <bechamel> Timitos: if it's a lead then a percentage makes no sense, if there is a percentage it means that it's an opporunorty, if it's cancelled or done percentage is also not needed | ||
| 2010-01-25 18:41 <bechamel> Timitos: but maybe you see other use cases ? | ||
| 2010-01-25 18:41 <Timitos> bechamel: you can either try to define the state as function field or you can use what you wrote as states for the propability field IMHO | ||
| 2010-01-25 18:42 <Timitos> bechamel: the propability field is necessary for computing a value for the pipeline. so you cannot mix it with a state | ||
| 2010-01-25 18:43 <sharoon> bechamel: Timitos: updated guys | ||
| 2010-01-25 18:44 <Timitos> sharoon: which date is stored by the date field? | ||
| 2010-01-25 18:45 <sharoon> Timitos: looks like its going to be the current datetime so we could reuse the create date | ||
| 2010-01-25 18:45 <Timitos> sharoon: +1 | ||
| 2010-01-25 18:45 -!- mourad(n=chatzill@wana-145-245-12-196.wanamaroc.com) has joined #tryton | ||
| 2010-01-25 18:46 <sharoon> bechamel: Timitos: can you give me an example of the usage of historize in the modules | ||
| 2010-01-25 18:46 <Timitos> sharoon: take a look at this module: http://hg.tryton.org/hgwebdir.cgi/modules/account_invoice_history/ | ||
| 2010-01-25 18:48 <Timitos> sharoon: i really recommend to use two fields 'state' and 'propability' instead of creating another object for the state | ||
| 2010-01-25 18:49 <sharoon> Timitos: not necessary i feel | ||
| 2010-01-25 18:50 -!- yangoon(n=mathiasb@p549F61F9.dip.t-dialin.net) has joined #tryton | ||
| 2010-01-25 18:50 <sharoon> Timitos: or is it like, x stage in lead and x stage in opprtunity? | ||
| 2010-01-25 18:50 <bechamel> Timitos: it will depends on how people will use it | ||
| 2010-01-25 18:51 <bechamel> the biggest problem with one field for both concept is how to filter out the record to get only opportunity (and not lead/cancelled/done) | ||
| 2010-01-25 18:51 <bechamel> *records *opportunities | ||
| 2010-01-25 18:52 <Timitos> bechamel: i think the object crm.opportunity needs a workflow and a state like sale order | ||
| 2010-01-25 18:52 <Timitos> the percentage is showing detailed state between opportunity -> confirmed | ||
| 2010-01-25 18:53 <sharoon> bechamel: i see the problem now | ||
| 2010-01-25 18:53 <sharoon> Timitos: lets keep this simple for now and work on the workflow later? | ||
| 2010-01-25 18:54 <Timitos> sharoon: adding a workflow will be easy when you use a simple state field like i proposed | ||
| 2010-01-25 18:55 <sharoon> i agree | ||
| 2010-01-25 18:55 <bechamel> I don't see any advantage for the workflow | ||
| 2010-01-25 18:57 <sharoon> bechamel: just buttons | ||
| 2010-01-25 18:57 <Timitos> bechamel: it is not really necessary for the moment. yes | ||
| 2010-01-25 19:00 <sharoon> bechamel: Timitos: so finally what abtt he percentage and status? i think its better to split them due to the filtering factor u pointed out | ||
| 2010-01-25 19:01 <Timitos> sharoon: +1 | ||
| 2010-01-25 19:02 <bechamel> sharoon: yes, and it can be hidden if status is not equal to opportunity | ||
| 2010-01-25 19:02 <sharoon> bechamel: +1 cool | ||
| 2010-01-25 19:02 <Timitos> bechamel: +1 | ||
| 2010-01-25 19:03 <sharoon> Done | ||
| 2010-01-25 19:03 <sharoon> i updated the CRM wiki | ||
| 2010-01-25 19:04 <Timitos> sharoon: as you already have history on crm.opportunity i think you can merge crm.opportunity and crm.opportunity.state | ||
| 2010-01-25 19:05 <Timitos> but be careful. for the moment there is still the view missing for the history table | ||
| 2010-01-25 19:05 <sharoon> Timitos: the view is important for history table | ||
| 2010-01-25 19:06 <Timitos> sharoon: i think there are two history aspects on this object model | ||
| 2010-01-25 19:07 <sharoon> Timitos: please can you explain? | ||
| 2010-01-25 19:07 <Timitos> ACTION is just thinking about | ||
| 2010-01-25 19:08 <Timitos> sharoon: i am not sure what you try to do with crm.opportunity.state | ||
| 2010-01-25 19:08 <Timitos> sharoon: the first aspect is to track all changes on the crm.opportunity object which can be done with history of the tryton kernel | ||
| 2010-01-25 19:09 <Timitos> the second aspect is to add further information about activities of the user or the lead/opportunity party i think | ||
| 2010-01-25 19:09 <Timitos> sharoon: does this fit to your aims? | ||
| 2010-01-25 19:10 <sharoon> Timitos: planning to use events and calendar todos with this | ||
| 2010-01-25 19:11 <sharoon> Timitos: crm.opportunity.state is to record the entire history of change with a comment. to find the time taken to convert etc etc... future, but the schema must be set now! | ||
| 2010-01-25 19:14 <Timitos> sharoon: i think exactly this is tryton kernel history doing. with the problem that for the moment the view is missing. but maybe it would be better to invest into this view than to do it another way | ||
| 2010-01-25 19:14 <bechamel> adding the history feature on the leads is more for stuff like "what was all my leads 6 month ago" (what i would call monitoring) and adding a O2M to opportunity.state is more for "OK this one lead, what was all the step made on it, what can I do next, etc" (more day to day operations) | ||
| 2010-01-25 19:14 <sharoon> bechamel: agree +1 | ||
| 2010-01-25 19:15 <Timitos> bechamel: sharoon already said that he wants to use calendar todo and events for future. so why not use the history function for history? | ||
| 2010-01-25 19:16 <bechamel> calendar stuff is advanced feature imo so it would be in a separate module | ||
| 2010-01-25 19:17 <Timitos> sharoon: i can understand your plans and it is possible like this. but maybe with history it could be easier as the history will be created by tryton | ||
| 2010-01-25 19:17 <Timitos> bechamel: yes | ||
| 2010-01-25 19:17 <bechamel> sharoon: don't forget that in tryton todo and event are real models (so events must be created and updated) not just a date field picked anywhere in the db | ||
| 2010-01-25 19:18 <sharoon> bechamel: just want to link it to the vents and todo in the calendar module | ||
| 2010-01-25 19:19 <sharoon> bechamel: just a link and i want to relate event & todo to partner | ||
| 2010-01-25 19:19 <Timitos> sharoon: +1 | ||
| 2010-01-25 19:24 <bechamel> sharoon: what I see is a wizard that will help the user to create a todo/event from the current lead, but once again it's not needed in the base module | ||
| 2010-01-25 19:26 -!- vengfulsquirrel(n=ian@c-69-181-194-95.hsd1.ca.comcast.net) has joined #tryton | ||
| 2010-01-25 19:27 -!- sharoon(n=sharoont@92.26.82.66) has left #tryton | ||
| 2010-01-25 19:32 -!- fil_(n=phil@blue.hands.com) has joined #tryton | ||
| 2010-01-25 19:33 -!- Timitos(n=timitos@88.217.184.172) has joined #tryton | ||
| 2010-01-25 19:41 -!- mourad(n=chatzill@wana-145-245-12-196.wanamaroc.com) has left #tryton | ||
| 2010-01-25 20:00 -!- mourad(n=chatzill@wana-145-245-12-196.wanamaroc.com) has joined #tryton | ||
| 2010-01-25 20:10 <cedk> why should we named it crm.opportunity? I find sale.opportunity better | ||
| 2010-01-25 20:13 -!- mourad(n=chatzill@wana-145-245-12-196.wanamaroc.com) has left #tryton | ||
| 2010-01-25 20:24 <bechamel> cedk: sale.opportunity? what would be the name of the module ? | ||
| 2010-01-25 20:30 <udono> bechamel: I vote for sale_opportunity as module name | ||
| 2010-01-25 20:31 <udono> (sharoon) | ||
| 2010-01-25 20:35 <bechamel> udono: yes, seems good | ||
| 2010-01-25 20:38 <cedk> bechamel: crm is like if we named other modules erp | ||
| 2010-01-25 20:38 <vengfulsquirrel> Who suggested crm? Maybe other crm related modules would be needed but would not work under sale? | ||
| 2010-01-25 20:38 <vengfulsquirrel> Just a thought. | ||
| 2010-01-25 20:39 <cedk> vengfulsquirrel: just find the right name for the right module | ||
| 2010-01-25 20:39 <cedk> vengfulsquirrel: it is sharoon who suggests crm | ||
| 2010-01-25 20:39 <cedk> vengfulsquirrel: I guess it is because he needs some crm functionnalities | ||
| 2010-01-25 20:40 <cedk> I still don't understand the opportunity.state Model | ||
| 2010-01-25 20:40 <cedk> and really dislike the selection 10%, 20% ... 90%, 100% | ||
| 2010-01-25 20:40 <cedk> I think it must be an integer | ||
| 2010-01-25 20:43 <bechamel> cedk: maybe sharoon choose crm because it's the name used in openerp | ||
| 2010-01-25 20:47 <bechamel> cedk: what do you think about using a model to store (date, state, comment) vs using historisation ? | ||
| 2010-01-25 20:49 <udono> bechamel: I think 'crm' is a good meta name for a collection of different modules | ||
| 2010-01-25 21:02 <cedk> bechamel: I think history can do the job | ||
| 2010-01-25 21:03 <bechamel> cedk: actually one can show the history of the current record in a readonly O2M | ||
| 2010-01-25 21:04 <cedk> bechamel: yes and even show only a subset of it | ||
| 2010-01-25 21:04 <cedk> bechamel: when state changed per example | ||
| 2010-01-25 21:04 <bechamel> cedk: yes good idea | ||
| 2010-01-25 21:04 <cedk> bechamel: I think it is really more powerful then any other kind of modeling | ||
| 2010-01-25 21:05 <bechamel> cedk: and it's easier for the user: change the state+save the form instead of: open a O2M, define state, close popup, save form | ||
| 2010-01-25 21:22 <udono> cedk: how many arguments can And(...), Or(...) in JSON DSL have? Only two, or more? | ||
| 2010-01-25 21:24 -!- sharoon(n=sharoont@host86-189-12-141.range86-189.btcentralplus.com) has joined #tryton | ||
| 2010-01-25 21:29 <udono> oh, I see, its only two arguments http://hg.tryton.org/hgwebdir.cgi/trytond/rev/403ba0f2a1e5#l21.114 | ||
| 2010-01-25 21:30 <bechamel> udono: two or more | ||
| 2010-01-25 21:31 <bechamel> udono: check the eval, it use reduce() on a list | ||
| 2010-01-25 21:33 <udono> bechamel: So I can use Not(And(a,b,c)) ? | ||
| 2010-01-25 21:34 <bechamel> udono: yes | ||
| 2010-01-25 21:37 <udono> bechamel: thanks | ||
| 2010-01-25 21:42 -!- sharoon(n=sharoont@host86-189-12-141.range86-189.btcentralplus.com) has joined #tryton | ||
| 2010-01-25 21:48 -!- sharoon(n=sharoont@host86-189-12-141.range86-189.btcentralplus.com) has joined #tryton | ||
| 2010-01-25 21:58 -!- sharoon(n=sharoont@host86-189-12-141.range86-189.btcentralplus.com) has joined #tryton | ||
| 2010-01-25 22:14 -!- sharoon(n=sharoont@host86-189-12-141.range86-189.btcentralplus.com) has joined #tryton | ||
| 2010-01-25 22:20 <udono> Did I need to explicit write states={'readonly': "active == False"} or is it predefined in model, when there is an active field? | ||
| 2010-01-25 22:23 <bechamel> udono: no it's not predefined | ||
| 2010-01-25 23:31 -!- rednul_(n=rednul@209-193-110-226.mammothnetworks.com) has joined #tryton | ||
| 2010-01-25 23:32 <cedk> mysql is *worst* than sqlite | ||
| 2010-01-25 23:33 <cedk> the max key length constraint of 1000 bytes is really a pain | ||
| 2010-01-25 23:33 <cedk> I don't think it will be possible to make a descent port of Tryton to MySQL | ||
| 2010-01-25 23:37 <cedk> I don't understand how OpenERP can run on MySQL | ||
| 2010-01-25 23:39 <cedk> or perhaps I don't use the right engine | ||
| 2010-01-25 23:47 <cedk> mysql by default use MyISAM instead of InnoDB | ||
| 2010-01-25 23:51 <bechamel> cedk: size constraints on char is also needed with InnoDB ? | ||
| 2010-01-25 23:51 <cedk> bechamel: don't know | ||
| 2010-01-25 23:51 <cedk> bechamel: now my init script doesn't work with InnoDB | ||
| 2010-01-25 23:53 <bechamel> but hey, with oepr and mysql you can enjoy "lower power consumption" xD | ||
| 2010-01-25 23:54 <cedk> bechamel: it seems my previous definition of foreign that was working doesn't any more with InnoDB | ||
| 2010-01-25 23:55 <bechamel> cedk: foreign what ? | ||
| 2010-01-25 23:55 <vengfulsquirrel> cedk: I think myisam used to ignore foreign keys, maybe that still hasn't changed. | ||
| 2010-01-25 23:56 <cedk> bechamel: foreign key | ||
| 2010-01-25 23:57 -!- sharoon(n=sharoont@host86-189-12-141.range86-189.btcentralplus.com) has left #tryton | ||
| 2010-01-25 23:57 -!- sharoon(n=sharoont@host86-189-12-141.range86-189.btcentralplus.com) has joined #tryton | ||
| 2010-01-25 23:57 <cedk> vengfulsquirrel: ok, it seems it is foreign key with on delete set null | ||
| 2010-01-25 23:57 <sharoon> cedk: http://mercurial.intuxication.org/hg/crm/ | ||
| 2010-01-25 23:58 <vengfulsquirrel> cedk: http://dev.mysql.com/doc/refman/5.5/en/ansi-diff-foreign-keys.html : '''For storage engines other than InnoDB, MySQL Server parses the FOREIGN KEY syntax in CREATE TABLE statements, but does not use or store it.''' |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!