| chat.freenode.net #tryton log beginning Fri Oct 17 00:00:01 CEST 2008 | ||
| 2008-10-17 00:22 -!- ikks(n=igor@190.12.153.202) has joined #tryton | ||
| 2008-10-17 03:23 <ovnicraft> ikks, hi | ||
| 2008-10-17 03:24 <ovnicraft> ikks, i am going to help to translate | ||
| 2008-10-17 03:43 <ikks> cool ovnicraft. | ||
| 2008-10-17 03:44 <ikks> I will create a user for you on intuxication. | ||
| 2008-10-17 03:44 <ikks> so you'll be able to improve the translations made so far. | ||
| 2008-10-17 03:44 <ovnicraft> ikks, thanks | ||
| 2008-10-17 03:45 <ovnicraft> and then create a localisation ;-) | ||
| 2008-10-17 03:45 <ikks> Well, it looks like there will be three localisations. | ||
| 2008-10-17 03:45 <ikks> be,ec and co. | ||
| 2008-10-17 03:45 <ikks> And I guess de also. | ||
| 2008-10-17 03:46 <ikks> Ecuador does not have an official chart of accounts afaik. | ||
| 2008-10-17 03:46 <ikks> But a starting one is good so accountants | ||
| 2008-10-17 03:46 <ikks> can have a guide. | ||
| 2008-10-17 03:47 <ikks> ovnicraft, visit | ||
| 2008-10-17 03:47 <ikks> http://mercurial.intuxication.org/ | ||
| 2008-10-17 03:47 <ikks> there you create an account for you | ||
| 2008-10-17 03:47 <ikks> and init a repo for account_ec | ||
| 2008-10-17 03:47 <ikks> I started to follow the steps for _be one, cedk told me it wasn't functional right now | ||
| 2008-10-17 03:48 <ikks> I plan to wait when things are ready to start colombian one. | ||
| 2008-10-17 03:50 <ovnicraft> ok | ||
| 2008-10-17 03:50 <ovnicraft> ikks, butt the base of concept is the same? | ||
| 2008-10-17 03:50 <ovnicraft> s/tt/t | ||
| 2008-10-17 03:51 <ikks> Yep, afaik the concepts are the same. | ||
| 2008-10-17 04:59 -!- ikks(n=igor@190.12.153.202) has joined #tryton | ||
| 2008-10-17 05:09 -!- markusleist(n=markus@n4-82.dsl.vianetworks.de) has joined #tryton | ||
| 2008-10-17 05:20 -!- yangoon(n=mathiasb@p549F4954.dip.t-dialin.net) has joined #tryton | ||
| 2008-10-17 07:52 -!- Timitos(n=Timitos@88.217.184.172) has joined #tryton | ||
| 2008-10-17 08:26 -!- GeE(n=gzuerche@host2.raptus.com) has joined #tryton | ||
| 2008-10-17 08:38 -!- Gedd(n=ged@77.109.115.165) has joined #tryton | ||
| 2008-10-17 08:55 <CIA-14> tryton: udono roundup * #137/icon tryton-delete is looking to harmless and meaningless: The edit-delete.svg from tango is looking much more alarming than the shredder. This icon even scales well in the 0ne2many list. | ||
| 2008-10-17 09:22 <CIA-14> tryton: udono roundup * #436/Add user setup dialog is a way to small: [new] After installing a new database the user setup dialog appears. But it is to small, I need to resize the dialog. | ||
| 2008-10-17 09:31 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton | ||
| 2008-10-17 10:40 <udono> Hello all | ||
| 2008-10-17 10:43 <udono> The states attribute for fields recognize readonly like: states={ "required": "type == 'person' and person_first_name == ''"}) | ||
| 2008-10-17 10:45 <udono> question: I have two fields, one of them needs to be required. Which one is required is unimportant, but it doesnt work: http://paste.pocoo.org/show/88275/ | ||
| 2008-10-17 10:47 <udono> There is not shown a blue or red background on the required fields if I open them or save them. | ||
| 2008-10-17 10:48 <udono> Or is an empty fields.Char != "" ? | ||
| 2008-10-17 10:58 -!- bechamel(n=user@user-85-201-14-207.tvcablenet.be) has joined #tryton | ||
| 2008-10-17 11:28 -!- bechamel(n=user@user-85-201-14-207.tvcablenet.be) has joined #tryton | ||
| 2008-10-17 11:39 <cedk> I find two commits in OpenERP that can be usefull: | ||
| 2008-10-17 11:39 <cedk> http://bazaar.launchpad.net/%7Eopenerp/openobject-server/trunk/revision/1170 | ||
| 2008-10-17 11:39 <cedk> http://bazaar.launchpad.net/%7Eopenerp/openobject-server/trunk/revision/1172 | ||
| 2008-10-17 11:40 <cedk> but I don't know if we need it for the release | ||
| 2008-10-17 11:40 <cedk> the one for attachment is not mandatory for the release | ||
| 2008-10-17 11:41 <cedk> but the fix for copy field with translate=True, must perhaps been added for the release | ||
| 2008-10-17 11:41 <cedk> what do you think? | ||
| 2008-10-17 11:45 -!- bechamel(n=user@user-85-201-14-207.tvcablenet.be) has joined #tryton | ||
| 2008-10-17 11:49 <cedk> bechamel: ping | ||
| 2008-10-17 11:55 <bechamel> cedk: yes ? | ||
| 2008-10-17 11:57 <cedk> bechamel: did you see my comments on the 2 commits from OpenERP? | ||
| 2008-10-17 11:58 <bechamel> cedk: no | ||
| 2008-10-17 11:58 <cedk> bechamel: ok I restart | ||
| 2008-10-17 11:58 <cedk> http://bazaar.launchpad.net/%7Eopenerp/openobject-server/trunk/revision/1170 | ||
| 2008-10-17 11:58 <cedk> http://bazaar.launchpad.net/%7Eopenerp/openobject-server/trunk/revision/1172 | ||
| 2008-10-17 11:58 <cedk> but I don't know if we need it for the release | ||
| 2008-10-17 11:58 <cedk> but the fix for copy field with translate=True, must perhaps been added for the release | ||
| 2008-10-17 11:58 <cedk> but the fix for copy field with translate=True, must perhaps been added for the release | ||
| 2008-10-17 11:58 <cedk> what do you think? | ||
| 2008-10-17 12:01 <bechamel> cedk: both are bugs, isn't it ? | ||
| 2008-10-17 12:03 <cedk> bechamel: attachment is not really a bug, it is more a behavior | ||
| 2008-10-17 12:04 <bechamel> cedk: yes | ||
| 2008-10-17 12:05 <bechamel> cedk: but copy of translations is a bug | ||
| 2008-10-17 12:07 <cedk> bechamel: yes | ||
| 2008-10-17 12:07 <cedk> bechamel: I will integrate it | ||
| 2008-10-17 12:25 -!- ikks(n=igor@190.12.153.202) has joined #tryton | ||
| 2008-10-17 12:37 <udono> cedk:I remember a bug in tiny erp, - a customer told me, - when duplicating a record including a translation... The customer had serious problems with this. Dont know if this relates to your changes?! | ||
| 2008-10-17 12:38 <cedk> udono: do you know which problems? | ||
| 2008-10-17 12:43 <udono> cedk: not correctly it has been tiny 4.0.3 ... It was on duplicated products. He created product without any translation, but on duplicate, there move some value into the translation and he cant find the product correctly, or something... | ||
| 2008-10-17 12:43 <udono> ...like this | ||
| 2008-10-17 12:44 <cedk> udono: ok, it is not related to the fix | ||
| 2008-10-17 12:46 <cedk> udono: but we fix this issue | ||
| 2008-10-17 12:47 <udono> cedk: of course, nothing else expected ;-) | ||
| 2008-10-17 12:48 <cedk> udono: I think I fixed when working at tiny | ||
| 2008-10-17 13:02 -!- yangoon(n=mathiasb@p549F4954.dip.t-dialin.net) has joined #tryton | ||
| 2008-10-17 13:07 <CIA-14> tryton: C?dric Krier <ced@b2ck.com> default * 1102:56d46031ed16 trytond/trytond/osv/orm.py: Fix copy records with field translatable | ||
| 2008-10-17 13:07 <cedk> do I make the fix for the access right on attachment ? | ||
| 2008-10-17 13:11 <bechamel> cedk: will it impact the webdav ? I imagine that one can allow somebody to add a document on a webdav directory and disallow this same user to acces in the cliebt the record linked to this directory. | ||
| 2008-10-17 13:13 <cedk> bechamel: no with the webdav, the user that doesn't have access to a record, can not add an attachemtn | ||
| 2008-10-17 13:19 <cedk> bechamel: we can see this fix like a security fix | ||
| 2008-10-17 13:23 <bechamel> cedk: yes this is what i said later | ||
| 2008-10-17 13:24 <cedk> bechamel: ok I will work on it | ||
| 2008-10-17 13:51 <cedk> udono: for the issue436, is the title right ? | ||
| 2008-10-17 13:51 <cedk> udono: or is there an other issue than the wizard size for user? | ||
| 2008-10-17 13:52 <udono> oh yes, I mixt up two bugs... i correct them | ||
| 2008-10-17 13:53 <CIA-14> tryton: udono roundup * #437/The progressbar dialog is to big, it looks ugly: [new] The progressbar is to wide and to hight. It would be good, if it is as small as possible. | ||
| 2008-10-17 13:54 <udono> cedk: fixed, thanx | ||
| 2008-10-17 13:55 <CIA-14> tryton: C?dric Krier <ced@b2ck.com> default * 851:4b65801d40a0 tryton/tryton/gui/window/view_form/view/form_gtk/parser.py: Fix compute of the requested size of notebook in form view for issue436 | ||
| 2008-10-17 13:55 <udono> Question: I have two fields, one of them needs to be required. Which one of the both required is unimportant, but one of the two fields must be filled with text. I try this: http://paste.pocoo.org/show/88275/ But it doesnt work as expected: There is neither shown a blue background on the required fields if I open them, nor a red background on saving them. | ||
| 2008-10-17 13:55 <CIA-14> tryton: ced roundup * #436/Add user setup dialog is a way to small: [resolved] Fix with changeset 4b65801d40a0 | ||
| 2008-10-17 13:58 <cedk> udono: because empty field will have the False value | ||
| 2008-10-17 13:58 <cedk> udono: you must test bool(person_last_name) | ||
| 2008-10-17 13:59 <cedk> udono: for the issue437, I don't understand the progressbar is small | ||
| 2008-10-17 13:59 <cedk> udono: just 3 lines of comments and one animation | ||
| 2008-10-17 14:01 <CIA-14> tryton: ced roundup * #437/The progressbar dialog is to big, it looks ugly: [chatting] Can you put a screenshot of the problem? | ||
| 2008-10-17 14:02 <udono> cedk: ups, maybe it depends on my window preferences (save window size)? I test... | ||
| 2008-10-17 14:03 <cedk> udono: put a screenshot | ||
| 2008-10-17 14:04 <udono> cedk: no, It is my fault. I resized, and now it works. | ||
| 2008-10-17 14:04 <udono> cedk: I close the bug | ||
| 2008-10-17 14:06 <CIA-14> tryton: udono roundup * #437/The progressbar dialog is to big, it looks ugly: [resolved] >for the issue437, I don't understand the progressbar is small >just 3 lines of comments and one animation ups, maybe it depends on my ... | ||
| 2008-10-17 14:10 <udono> cedk: Thaks for the test bool, it works good. | ||
| 2008-10-17 15:44 <cedk> udono: just one remarks, you must be carefull with the call of set_size_request in the client | ||
| 2008-10-17 15:45 <cedk> udono: because it make the widget less dynamic | ||
| 2008-10-17 15:51 <CIA-14> tryton: C?dric Krier <ced@b2ck.com> default * 852:d12ca9f64d38 tryton/tryton/ (3 files in 2 dirs): Remove bad size_request | ||
| 2008-10-17 16:05 <CIA-14> tryton: C?dric Krier <ced@b2ck.com> default * 1103:5b52307e79b3 trytond/trytond/ir/attachment.py: | ||
| 2008-10-17 16:05 <CIA-14> tryton: Add check access for the res_model of attachments to use the access right of | ||
| 2008-10-17 16:05 <CIA-14> tryton: the linked model (inspired by the OpenERP rev1172) | ||
| 2008-10-17 16:05 <CIA-14> tryton: C?dric Krier <ced@b2ck.com> default * 1104:203cb8663367 trytond/trytond/osv/orm.py: Add context when calling check of ir.model.access | ||
| 2008-10-17 16:05 <CIA-14> tryton: C?dric Krier <ced@b2ck.com> default * 1105:d66dfc6748c8 trytond/trytond/osv/orm.py: Fix get_eval for BrowseRecordNull | ||
| 2008-10-17 16:14 <cedk> I fix the attachment access right | ||
| 2008-10-17 16:15 <cedk> It was a good idea to fix it for this release as I find some other bugs :-) | ||
| 2008-10-17 17:27 <CIA-14> tryton: Udo Spallek <info@virtual-things.biz> default * 853:f13f910f6147 tryton/tryton/gui/main.py: | ||
| 2008-10-17 17:27 <CIA-14> tryton: "Previous" entry is duplicated in file menu. Removed | ||
| 2008-10-17 17:27 <CIA-14> tryton: hG: Enter commit message. Lines beginning with 'HG:' are removed. | ||
| 2008-10-17 17:27 <CIA-14> tryton: C?dric Krier <ced@b2ck.com> default * 854:bc7f56732784 tryton/: merge | ||
| 2008-10-17 17:27 <CIA-14> tryton: udo.spallek * r233 /wiki/DocumentationModules.wiki: Initial | ||
| 2008-10-17 17:27 <CIA-14> tryton: cedric.krier@b2ck.com * r234 /wiki/DocumentationModules.wiki: Fix typo | ||
| 2008-10-17 17:27 <CIA-14> tryton: cedric.krier@b2ck.com * r235 /wiki/DocumentationModules.wiki: Fix typo | ||
| 2008-10-17 17:33 <cedk> Timitos, udono: can we talk about the module relationship? | ||
| 2008-10-17 17:37 <udono> cedk, yes | ||
| 2008-10-17 17:38 <cedk> I talk with bechamel and there is some divergent points | ||
| 2008-10-17 17:38 <udono> ok | ||
| 2008-10-17 17:38 <cedk> we think that the split of the name into first,last name is not really good | ||
| 2008-10-17 17:39 <cedk> because it introcudes a lot of problems | ||
| 2008-10-17 17:39 <cedk> how to we display the name first + last or last + first | ||
| 2008-10-17 17:39 <cedk> somes have more than just first and last name | ||
| 2008-10-17 17:39 <cedk> company doesn't have two names | ||
| 2008-10-17 17:39 <cedk> etc... | ||
| 2008-10-17 17:39 <udono> company has on name... | ||
| 2008-10-17 17:40 <cedk> We think that it is not as simple as we though when we make basic module | ||
| 2008-10-17 17:40 <cedk> so there is any problem to add this functionnality with a module by inheritance | ||
| 2008-10-17 17:41 <cedk> like relationship_multi_name ? | ||
| 2008-10-17 17:41 <udono> no problem | ||
| 2008-10-17 17:42 <udono> we have the type defined, so we can divide the names like we want in an addon module. | ||
| 2008-10-17 17:42 <cedk> udono: that is the next point | ||
| 2008-10-17 17:43 <udono> :-) | ||
| 2008-10-17 17:43 <cedk> we are not sure about the usefull of the type separation | ||
| 2008-10-17 17:44 <cedk> in fact not for the basic module | ||
| 2008-10-17 17:44 <cedk> as any others module need this information (for now) | ||
| 2008-10-17 17:44 <udono> cedk: thanb everything stays as it is? | ||
| 2008-10-17 17:45 <bechamel> cedk: udono: whats the url of the repo again? i would like to re-read it | ||
| 2008-10-17 17:45 <cedk> udono: no the split of email, website out of the address is good | ||
| 2008-10-17 17:45 <cedk> bechamel: http://mercurial.intuxication.org/hg/relationship | ||
| 2008-10-17 17:46 <bechamel> cedk: thx | ||
| 2008-10-17 17:46 <cedk> udono: there is also the informal, internal flags | ||
| 2008-10-17 17:46 <cedk> I don't see the usefull of this | ||
| 2008-10-17 17:46 <bechamel> cedk: i was search in the /tryton/ list | ||
| 2008-10-17 17:46 <udono> cedk: informal and internal can be removed | ||
| 2008-10-17 17:47 <cedk> bechamel: it is not yet added | ||
| 2008-10-17 17:49 <cedk> there is also the relationship.party.legalform | ||
| 2008-10-17 17:49 <udono> cedk: type separation is generic for a module about persons and organisations. You cant build any higer level without this decision... | ||
| 2008-10-17 17:49 <cedk> I'm not sure for the name | ||
| 2008-10-17 17:50 <cedk> udono: we don't need for any modules for now ? | ||
| 2008-10-17 17:50 <udono> cedk: no, but it is a generic information if we are talking about persons or organisations. | ||
| 2008-10-17 17:52 <udono> cedk: You cant say a module is for persons AND organisations, and dont build this decision in, I think | ||
| 2008-10-17 17:53 <bechamel> the criterium to include feature is "does everyone need it ?". I.e, does a stock-centric usage or an account only usage need-it. If not i shold be an optinal module (moreover if the feature is easy to add with inheritance) | ||
| 2008-10-17 17:53 <cedk> udono: I don't understand | ||
| 2008-10-17 17:53 <udono> cedk: I try to explain | ||
| 2008-10-17 17:54 <udono> what we have now is mainly the tiny partner module | ||
| 2008-10-17 17:54 <udono> there we can create companys with addresses and persons connected to the addresses | ||
| 2008-10-17 17:55 <udono> just b2b is meaning ful for this model | ||
| 2008-10-17 17:55 <cedk> udono: no, there is no person connected to the addresses | ||
| 2008-10-17 17:55 <udono> cedk: Contact name? | ||
| 2008-10-17 17:55 <cedk> udono: you can see that when you create a employee (person) it is linked to a party not an address | ||
| 2008-10-17 17:55 <cedk> udono: contact name is for the addresse | ||
| 2008-10-17 17:56 <cedk> udono: like "Building Block B" | ||
| 2008-10-17 17:56 <cedk> udono: or for the name of the mailbox | ||
| 2008-10-17 17:56 <cedk> udono: but not for a person of a company | ||
| 2008-10-17 17:57 <cedk> we don't reproduce the modelisation errors of tinyerp | ||
| 2008-10-17 17:57 <udono> cedk::-) | ||
| 2008-10-17 17:57 <bechamel> maybe one should define a basic party which will be the parent class of two other class: person and organisation, that will be esaier/cleaner to define peoples in the system | ||
| 2008-10-17 17:57 <cedk> only the one that we know :-) | ||
| 2008-10-17 17:58 <cedk> bechamel: I think it is more complicate | ||
| 2008-10-17 17:59 <bechamel> cedk: yes, but imho the current modelisation is missing something | ||
| 2008-10-17 17:59 <cedk> bechamel: what ? | ||
| 2008-10-17 17:59 <udono> afk | ||
| 2008-10-17 17:59 <bechamel> cedk: the problems udono try to adress | ||
| 2008-10-17 18:00 <cedk> the fact that there is no difference between a company and a person | ||
| 2008-10-17 18:00 <cedk> ? | ||
| 2008-10-17 18:00 <bechamel> cedk: name on party doesnt make sens for organisations not for people | ||
| 2008-10-17 18:00 <cedk> bechamel: don't understand | ||
| 2008-10-17 18:02 <cedk> organisation has name and people has name | ||
| 2008-10-17 18:02 <bechamel> cedk: on a people it could be interesting to put a link to is organisation (which is another party) but for an organisation it does'nt make sense | ||
| 2008-10-17 18:02 <cedk> bechamel: organisation can be a sub-organisation | ||
| 2008-10-17 18:02 <udono> back | ||
| 2008-10-17 18:02 <bechamel> cedk: yes but it's another field | ||
| 2008-10-17 18:03 <cedk> but it is not needed for basic use | ||
| 2008-10-17 18:04 <cedk> to make business with a company, you don't need to know his employee nor his companies | ||
| 2008-10-17 18:04 <cedk> and to make business with people, you don't need to know where they work | ||
| 2008-10-17 18:05 <udono> cedk: people vs organization is a general decision we need to take care about. Its out of sense to cut them in another module. Its like you cut taxes or types or defferal methods away from account module. | ||
| 2008-10-17 18:05 <cedk> afk not for major business | ||
| 2008-10-17 18:05 <bechamel> cedk: OR maybe the solution is to keep the current party object and extend it in two ways: one relationship.party.people and one relationship.party.organisation. like that other module can stay the same and one can use different sub-model of party in different situation | ||
| 2008-10-17 18:05 <udono> bechamel: good idea, but | ||
| 2008-10-17 18:06 <cedk> udono: no, because those account stuffs are used in the module | ||
| 2008-10-17 18:06 <cedk> so it is not the same | ||
| 2008-10-17 18:07 <cedk> bechamel: I'm not again the possibility to separate people and organisation but for me it is not mandatory for simple module | ||
| 2008-10-17 18:07 <udono> bechamel: ... the odd design of the company module... building an own person/organisation structure just for the enterprise you run yourself, but not the other ones... | ||
| 2008-10-17 18:08 <cedk> udono: this is because we need specific information about the current company | ||
| 2008-10-17 18:08 <cedk> it is not need to modelise every things | ||
| 2008-10-17 18:09 <cedk> for accounting stuff, a person or an organisation are the same | ||
| 2008-10-17 18:09 <udono> cedk: for me I am talking about generic design, not special implementation | ||
| 2008-10-17 18:09 <bechamel> cedk: yes my opinion is to keep the base module like that, the only problem for me with the current module is to filter some party in some situation, like for the adresses, there are filtered one can filter them for invoicing or for delivery | ||
| 2008-10-17 18:10 <cedk> as we have a platform that allow to extend easily models, we must keep module as simple as possible | ||
| 2008-10-17 18:11 <cedk> bechamel: this is a ergonomic question, and the solution will not be easy | ||
| 2008-10-17 18:11 <udono> cedk: for me its way to simple like it is | ||
| 2008-10-17 18:11 <udono> cedk: but just because of the company module... | ||
| 2008-10-17 18:11 <bechamel> cedk: checkboxes like on the adresses are ok, no ? | ||
| 2008-10-17 18:12 <cedk> bechamel: yes, but I think you talk about the possibility to just see invoice address on a partner form ? | ||
| 2008-10-17 18:12 <cedk> udono: what is the problem of company module ? | ||
| 2008-10-17 18:13 <bechamel> cedk: a just don't want to see a customer when i search in the party field on on purchase order, a supplier on the sale form, etc etc | ||
| 2008-10-17 18:14 <udono> cedk: since it uses inherits not inherit it doesent take care about extension modules of relationship | ||
| 2008-10-17 18:14 <udono> cedk: replace the checkbox with a 0ne2many | ||
| 2008-10-17 18:14 <udono> sorry bechamel: replace the checkbox with a 0ne2many | ||
| 2008-10-17 18:15 <cedk> bechamel: but it depends on how a company works | ||
| 2008-10-17 18:16 <cedk> bechamel: they can want to enforce which party can be supplier | ||
| 2008-10-17 18:16 <bechamel> udono: why a o2m ? | ||
| 2008-10-17 18:16 <cedk> bechamel: and some doesn't want | ||
| 2008-10-17 18:16 <cedk> bechamel: so if you put this constraint on the base module, it is not possible to have the other behavior | ||
| 2008-10-17 18:16 <udono> bechamel: because an address can be for "shipment" and "invoice" | ||
| 2008-10-17 18:17 <cedk> and once again this kind of constraint must be developped in a module | ||
| 2008-10-17 18:17 <bechamel> cedk: the solution is to make default true on all checkbox, like that no filter by default | ||
| 2008-10-17 18:17 <cedk> udono: we have one check box by type, so it is like a one2many but we find it more eyecandy in the address form | ||
| 2008-10-17 18:18 <bechamel> udono: there are several checkboxes, one by main "role" | ||
| 2008-10-17 18:18 <cedk> bechamel: I don't talk about addresses | ||
| 2008-10-17 18:18 <cedk> bechamel: I talk about party | ||
| 2008-10-17 18:18 <cedk> bechamel: addresses are filtered with the right checkbox (except if there is a bug) | ||
| 2008-10-17 18:20 <bechamel> cedk: the problem is not the party module by itself the checkboxes must be in the other modules (like for the chekbixes on addresses ) the party module just have to provide a group in the view | ||
| 2008-10-17 18:20 <cedk> bechamel: which group ? | ||
| 2008-10-17 18:20 <bechamel> cedk: a <group> in the view | ||
| 2008-10-17 18:21 <cedk> it is really simple to write a little module that add this functionnality | ||
| 2008-10-17 18:21 <cedk> bechamel: because what you talk about is just for supplier | ||
| 2008-10-17 18:22 <cedk> bechamel: because you will not do the same for customrs | ||
| 2008-10-17 18:22 <bechamel> cedk: and customers | ||
| 2008-10-17 18:22 <cedk> bechamel: why will you prevent a company to sell to somebody ? | ||
| 2008-10-17 18:23 <bechamel> cedk: it's to prevent mistakes | ||
| 2008-10-17 18:23 <cedk> you can write a module named "realtionship_supplier" | ||
| 2008-10-17 18:23 <cedk> bechamel: mistake about what ? | ||
| 2008-10-17 18:24 <cedk> all this will generated is that people will encode many times the same party because they don't find him | ||
| 2008-10-17 18:24 <cedk> because it has not the right check box | ||
| 2008-10-17 18:25 <cedk> as I say I understand that for somes it is usefull to have this behavior for supplier | ||
| 2008-10-17 18:25 <bechamel> cedk: about not selecting the right party, and my experience tell me that new users are always disturbed when they see that customer are available on purchase and vice-versa | ||
| 2008-10-17 18:25 <cedk> but the best to handle this is by a module | ||
| 2008-10-17 18:26 <cedk> bechamel: because they don't realise that you can have a party that is supplier and customer | ||
| 2008-10-17 18:26 <bechamel> cedk: it will not be one module it will be, invoice_filter, sale_filter and purchase_filter etc, one need to update every field that point to relationship.party | ||
| 2008-10-17 18:26 <cedk> and once again, it is just a simple module that I can write in 1 hour | ||
| 2008-10-17 18:27 <cedk> and it has no sence to create this for customers | ||
| 2008-10-17 18:27 <cedk> every body can be customers | ||
| 2008-10-17 18:27 <bechamel> cedk: not in most of the businesses | ||
| 2008-10-17 18:27 <cedk> bechamel: give an example ? | ||
| 2008-10-17 18:27 <udono> cedk: for me the checkbox solution is just short solution. When you like to introduce more attributes later in some other modules, everything will look worse with a bunch of checkboxes around. Why not introduce simple general roles module for this and a one2many which is appended by new modules? | ||
| 2008-10-17 18:28 <bechamel> cedk: i dont want to forbid it i just want to allow the user to filter results it's different | ||
| 2008-10-17 18:28 <cedk> bechamel: you already have it, you write a function field that allows this | ||
| 2008-10-17 18:29 <cedk> udono: I don't understand a one2many is more complicated than a checkbox | ||
| 2008-10-17 18:30 <udono> cedk: but its everytime clean | ||
| 2008-10-17 18:30 <bechamel> cedk: probably udono was talking about a m2m | ||
| 2008-10-17 18:30 <cedk> bechamel: there is a view "Suppliers" so you can filter on supplier | ||
| 2008-10-17 18:30 <udono> bechamel: yep, sorry | ||
| 2008-10-17 18:31 <cedk> I need more examples | ||
| 2008-10-17 18:31 <cedk> and there is still the categories field | ||
| 2008-10-17 18:32 <cedk> but with a many2many, it is more difficult to filter | ||
| 2008-10-17 18:32 <cedk> if you want all the party that has "a" and "b" | ||
| 2008-10-17 18:32 <bechamel> cedk: the supplier view work the way around it gives parties for which a purchase have been made (in the past), what i talk about is when the user is in the purchase form he only see party he want to see there | ||
| 2008-10-17 18:32 <cedk> we can not handle this query | ||
| 2008-10-17 18:33 <bechamel> cedk: which one ? | ||
| 2008-10-17 18:33 <cedk> bechamel: but it is a simple module to add this | ||
| 2008-10-17 18:33 <cedk> bechamel: don't understand | ||
| 2008-10-17 18:34 <bechamel> cedk: which query is not handled ? | ||
| 2008-10-17 18:34 <udono> cedk: examples: Implemetation for school: Teacher/Scholar/Parent/Administration/... for Healthcare: Patient/Nurse/Doctor/Insurance | ||
| 2008-10-17 18:34 <cedk> bechamel: as search on many2many that have "a" and "b" | ||
| 2008-10-17 18:35 <bechamel> cedk: aj ok | ||
| 2008-10-17 18:35 <udono> cedk: dont understand? | ||
| 2008-10-17 18:35 <cedk> and what I try to explain, is that with modularity, it is the freedom | ||
| 2008-10-17 18:35 <cedk> as you can change anything | ||
| 2008-10-17 18:36 <cedk> udono: so you have three category: "supplier", "customer", "other" | ||
| 2008-10-17 18:36 <udono> cedk: :-) | ||
| 2008-10-17 18:36 <cedk> udono: if you want to search for every party that are "supplier" and "customer" | ||
| 2008-10-17 18:36 <cedk> udono: we can not make this with one search | ||
| 2008-10-17 18:36 <bechamel> cedk: this kind of query looks like: select party.id, count(party.id) as tot from party join role where role.type in list group by party.id having tot >= len(list) | ||
| 2008-10-17 18:36 <cedk> udono: so the client (GTK) can not make this query | ||
| 2008-10-17 18:37 <cedk> udono: you can do it with programmation | ||
| 2008-10-17 18:37 <cedk> bechamel: it works for only few queries | ||
| 2008-10-17 18:38 <cedk> what I try to say, it is that we must stay very generic and let every possibilitty open in the basic modules | ||
| 2008-10-17 18:38 <cedk> because we must let the possibility to modify it with other modules | ||
| 2008-10-17 18:38 <bechamel> cedk: this gives the parties that have all the category whe are searching for | ||
| 2008-10-17 18:39 <cedk> so if you implement a model that is too strict, you can not change it | ||
| 2008-10-17 18:39 <udono> cedk: ok I understand | ||
| 2008-10-17 18:39 <cedk> bechamel: yes it works for the query I say, but there is other query like that where it will not work | ||
| 2008-10-17 18:39 <udono> cedk: but what about a module which is to simple to extend? | ||
| 2008-10-17 18:40 <cedk> udono: I don't find an example | ||
| 2008-10-17 18:40 <udono> cedk: what about my concerns about the company module? | ||
| 2008-10-17 18:40 <cedk> udono: I don't understand the problem with company module | ||
| 2008-10-17 18:40 <bechamel> udono, cedk: let's talk about one feature at time and see if it's possible to do it in another module | ||
| 2008-10-17 18:40 <cedk> but can we stop for 20min the conversation, I need to go to the shop before it closes | ||
| 2008-10-17 18:41 <udono> cedk: We putted all the things inside the party module, because the company module sole inherits the party module, not the other modules, that inherit party... | ||
| 2008-10-17 18:41 <bechamel> cedk: i have to leave too | ||
| 2008-10-17 18:41 <udono> bye | ||
| 2008-10-17 18:41 <cedk> udono: but you can depend on company module | ||
| 2008-10-17 18:41 <cedk> udono: and change it | ||
| 2008-10-17 18:42 <bechamel> udono, cedk: bye, and one can continue by mail | ||
| 2008-10-17 18:42 <CIA-14> tryton: udo.spallek * r236 /wiki/DocumentationClient.wiki: Created wiki page through web user interface. | ||
| 2008-10-17 18:42 <udono> cedk: But I like to change the party module and be sure that the changes are inherited by the other modules | ||
| 2008-10-17 18:43 <udono> bechamel: see u | ||
| 2008-10-17 18:43 <bechamel> udono: bye | ||
| 2008-10-17 18:53 <udono> cedk: http://www.tryton.org/~irclog/2008-08-11.log.html#t2008-08-11_08:05 | ||
| 2008-10-17 18:56 -!- X0d_of_N3d_(i=C-C_C-X@gateway/tor/x-c51547db75e12efc) has joined #tryton | ||
| 2008-10-17 19:03 <cedk> back | ||
| 2008-10-17 19:04 <cedk> udono: there is many possibilities for the issue you can find | ||
| 2008-10-17 19:04 <cedk> udono: one will be to have default value that works for company | ||
| 2008-10-17 19:04 <cedk> udono: an other one is to depend on company and add the necessary code on company model | ||
| 2008-10-17 19:07 <udono> cedk: Ok, than we can leave the relationship module like it is. Because I can extend like I want, and the only module which need extra service is the company module... | ||
| 2008-10-17 19:08 <udono> cedk: last point is the namespace of the "relationship" module, wich actually doesnt do anything about "relationships" its just 'party' | ||
| 2008-10-17 19:08 <udono> cedk: I know its a boring job to rewrite namespaces... | ||
| 2008-10-17 19:09 <udono> cedk: but for me pre release is the last possible chance to do... | ||
| 2008-10-17 19:10 <cedk> udono: I think also about that | ||
| 2008-10-17 19:10 <cedk> udono: and I don't see the problem | ||
| 2008-10-17 19:10 <cedk> udono: for me the module is about the relationship between the company and others | ||
| 2008-10-17 19:14 <udono> cedk: actually its about partys... I think of a CRM module later which is about relationships... generic names are rare... and party_xxx is a better/smaller prefix... | ||
| 2008-10-17 19:14 <udono> cedk: The module doesent implement any relationships TO other modules, its a generic party module | ||
| 2008-10-17 19:14 <cedk> udono: CRM is a subset because it about customers | ||
| 2008-10-17 19:15 <cedk> udono: but will be extended to add stuff | ||
| 2008-10-17 19:15 <udono> cedk: Yes, my plannings are not CRM its RM generic relationship management... | ||
| 2008-10-17 19:16 <udono> cedk: more over its relationship planning and /management | ||
| 2008-10-17 19:17 <cedk> udono: what you emplemenent is relationship between party, but here the simple module is just relation between the company and others | ||
| 2008-10-17 19:18 <cedk> udono: and the category is for specification of the relation | ||
| 2008-10-17 19:18 <udono> cedk: the actual relationship module doesn't provide any infrastructure for relationship. It just provide Infrastructure for party. Even the own enterprise is a party. | ||
| 2008-10-17 19:19 <cedk> udono: it is the base | ||
| 2008-10-17 19:19 <udono> cedk: category is not relationship, its just information about informational roles. | ||
| 2008-10-17 19:24 <cedk> udono: but you aggre that your module just extend the party | ||
| 2008-10-17 19:25 <udono> cedk: yes, after your clearing that company is extendable, I just like to have a very simple party module. | ||
| 2008-10-17 19:25 <udono> cedk: for me the address and contact part could go in another module, too. | ||
| 2008-10-17 19:25 <udono> cedk: and just a single name, no internal, no informal checkbox | ||
| 2008-10-17 19:26 <cedk> wait, if you go like that we will make one module per model | ||
| 2008-10-17 19:27 <udono> cedk: one module per generic model. Its like account and account_invoice for me... | ||
| 2008-10-17 19:27 <cedk> udono: in account_invoice there is invoice.line, payment_term ... | ||
| 2008-10-17 19:27 -!- ikks(n=igor@190.12.153.202) has joined #tryton | ||
| 2008-10-17 19:28 <udono> cedk: yes, and? | ||
| 2008-10-17 19:29 <udono> cedk: Its not so important for me is address is inside or outside the module party. But later it will not this easy to implement alternative contact mechanisms... | ||
| 2008-10-17 19:29 <udono> s/is/if/ | ||
| 2008-10-17 19:30 <cedk> udono: like ? | ||
| 2008-10-17 19:31 <udono> cedk: Read page 47 to 58... | ||
| 2008-10-17 19:32 <udono> cedk: Facility management etc... its a model between party and address or contact... its for institutions like hospitals, where you "address" floors, rooms and so on... | ||
| 2008-10-17 19:33 <udono> cedk: but its equal, both ways are possible: address inside party and outside party. More clean is outside party. | ||
| 2008-10-17 19:36 <udono> cedk: another thing we can put in an alternate module is relationship.party.legalform aka the old party type... | ||
| 2008-10-17 19:37 <cedk> udono: but it is the facility can work with addresses, it is not incompatible | ||
| 2008-10-17 19:40 <udono> cedk: I told you it will work, but its not this clean, because there is an need to disconnect the addresses from the party and reconnect them to the party over some intermediate modules. | ||
| 2008-10-17 19:40 <cedk> udono: I don't say use the addresses for this | ||
| 2008-10-17 19:40 <cedk> udono: you can add an other model to handle this | ||
| 2008-10-17 19:42 <cedk> and if you think about hospital, you must have all the rooms inside the system and just select one | ||
| 2008-10-17 19:45 <udono> cedk: ok, I understand, but the addresses are not imediatly connected to the party, if you see the party contact mechanism (Expanded) on which the Facility managemant is based... but as I told, its not this important for me, its a minor design decision... | ||
| 2008-10-17 19:50 <cedk> udono: it is true that we can remove the relationship.party.type model | ||
| 2008-10-17 19:51 <cedk> udono: and I think that we sould use the name_get function to display the party name in reports like invoice, etc... | ||
| 2008-10-17 19:51 <cedk> instade of using name | ||
| 2008-10-17 19:51 <cedk> it will allow easier implementation of extended modules | ||
| 2008-10-17 19:52 <cedk> and add the contact mecanism for email, website, phone, ... | ||
| 2008-10-17 19:52 <udono> cedk: and what about namespace party? (since we need to rewrite all other modules because of name_get?) | ||
| 2008-10-17 19:52 <udono> cedk: add contact mechanism means addon module? | ||
| 2008-10-17 19:54 <cedk> udono: yes contact machanism can be on other module | ||
| 2008-10-17 19:54 <udono> cedk: ok, no problem, good decision | ||
| 2008-10-17 19:55 <cedk> udono: for the name, I don't know | ||
| 2008-10-17 19:57 <udono> cedk: Is it the dump work to realise? | ||
| 2008-10-17 19:57 <udono> cedk: I help! | ||
| 2008-10-17 19:57 <cedk> udono: no, it is the fact that this module will be the base for any CRM implementation | ||
| 2008-10-17 19:57 <cedk> udono: or any other stuf linked to relation | ||
| 2008-10-17 19:59 <udono> cedk: yes, and its not only for relationships and CRM, its simply for all kind of party, nothing more. Any other functionality is added in a seperate module. | ||
| 2008-10-17 20:00 <cedk> udono: yes, but menu structure will be confusing | ||
| 2008-10-17 20:00 <udono> cedk: why? | ||
| 2008-10-17 20:01 <udono> cedk: CRM and "Customer" partys are different things | ||
| 2008-10-17 20:01 <cedk> udono: but it is all about relationship | ||
| 2008-10-17 20:02 <udono> cedk: the first is for the changeing relationships and the second is for the standing data | ||
| 2008-10-17 20:02 <udono> cedk: party is just a base for relationships, but not the same | ||
| 2008-10-17 20:03 <cedk> udono: for me it is the first step | ||
| 2008-10-17 20:04 <udono> cedk: of course its a first step, its the _base_ for relationships, but it is not the same then relationships. This is what I mean. | ||
| 2008-10-17 20:05 <cedk> udono: we can change the description in __tryton__.py | ||
| 2008-10-17 20:05 <cedk> udono: but I think that the namespacefor Party must be relationship.party | ||
| 2008-10-17 20:06 <udono> if party is the base, than it must be party.relationship... | ||
| 2008-10-17 20:06 <udono> but it actually did nt do any relationship... | ||
| 2008-10-17 20:06 <cedk> no because we will have relationship.relation, relationship.role, ... | ||
| 2008-10-17 20:07 <udono> ACTION despair | ||
| 2008-10-17 20:07 <cedk> and what about the menu ? | ||
| 2008-10-17 20:07 <udono> cedk: we will have party.relationship, party.role | ||
| 2008-10-17 20:08 <udono> Menu is "Party" or "Parties" | ||
| 2008-10-17 20:08 <udono> ...since we have divided out People and Organisation ... | ||
| 2008-10-17 20:09 <udono> Menu for Relationships is "Relationship" | ||
| 2008-10-17 20:10 <udono> ... when we have it | ||
| 2008-10-17 20:13 <udono> Why not take some small concepts and namespaces from Silverston? | ||
| 2008-10-17 20:18 <cedk> ACTION need to think | ||
| 2008-10-17 20:23 <udono> He is an experienced well known datamodeler, he is english native speaker, and his resources are generally well reviewed (even the two bad reviews I found are telling that the models are generic... and this is what we want): http://www.amazon.ca/review/product/0471380237/ref=cm_cr_pr_link_1?_encoding=UTF8&sortBy=bySubmissionDateDescending http://www.amazon.co.uk/review/product/0471380237/ref=cm_cr_dp_all_helpful/275-9946650-3929955?_e | ||
| 2008-10-17 20:23 <udono> ubmissionDateDescending http://www.amazon.de/review/product/0471380237/ref=cm_cr_dp_all_helpful/275-7110011-8755911?_encoding=UTF8&coliid=&showViewpoints=1&colid=&sortBy=bySubmissionDateDescending | ||
| 2008-10-17 20:23 <udono> And its an external reference... | ||
| 2008-10-17 20:29 <cedk> udono: let think about it for the WE | ||
| 2008-10-17 20:29 <cedk> udono: we will see monday | ||
| 2008-10-17 20:32 <udono> cedk: no problem | ||
| 2008-10-17 20:40 <udono> afk | ||
| 2008-10-17 20:49 -!- Gedd(n=ged@77.109.115.165) has joined #tryton | ||
| 2008-10-17 21:32 -!- igor__(n=igor@190.12.153.202) has joined #tryton | ||
| 2008-10-17 22:29 <CIA-14> tryton: udo.spallek * r237 /wiki/DocumentationClient.wiki: Edited wiki page through web user interface. | ||
| 2008-10-17 22:29 <CIA-14> tryton: udo.spallek * r238 /wiki/DocumentationClient.wiki: Edited wiki page through web user interface. | ||
| 2008-10-17 23:54 -!- ovnicraft(n=ovnicraf@190.154.63.122) has left #tryton |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!