IRC logs of #tryton for Friday, 2008-10-17

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/!