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

chat.freenode.net #tryton log beginning Fri Oct 17 00:00:01 CEST 2008
-!- ikks(n=igor@190.12.153.202) has joined #tryton00:22
ovnicraftikks, hi03:23
ovnicraftikks, i am going to help to translate03:24
ikkscool ovnicraft.03:43
ikksI will create a user for you on intuxication.03:44
ikksso you'll be able to improve the translations made so far.03:44
ovnicraftikks, thanks03:44
ovnicraftand then create a localisation ;-)03:45
ikksWell, it looks like there will be three localisations.03:45
ikksbe,ec and co.03:45
ikksAnd I guess de also.03:45
ikksEcuador does not have an official chart of accounts afaik.03:46
ikksBut a starting one is good so accountants03:46
ikkscan have a guide.03:46
ikksovnicraft, visit03:47
ikkshttp://mercurial.intuxication.org/03:47
ikksthere you create an account for you03:47
ikksand init a repo for account_ec03:47
ikksI started to follow the steps for _be one, cedk told me it wasn't functional right now03:47
ikksI plan to wait when things are ready to start colombian one.03:48
ovnicraftok03:50
ovnicraftikks, butt the base of concept is the same?03:50
ovnicrafts/tt/t03:50
ikksYep, afaik the concepts are the same.03:51
-!- ikks(n=igor@190.12.153.202) has joined #tryton04:59
-!- markusleist(n=markus@n4-82.dsl.vianetworks.de) has joined #tryton05:09
-!- yangoon(n=mathiasb@p549F4954.dip.t-dialin.net) has joined #tryton05:20
-!- Timitos(n=Timitos@88.217.184.172) has joined #tryton07:52
-!- GeE(n=gzuerche@host2.raptus.com) has joined #tryton08:26
-!- Gedd(n=ged@77.109.115.165) has joined #tryton08:38
CIA-14tryton: 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.08:55
CIA-14tryton: 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.09:22
-!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton09:31
udonoHello all10:40
udonoThe states attribute for fields recognize readonly like: states={ "required": "type == 'person' and person_first_name == ''"})10:43
udonoquestion: 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/10:45
udonoThere is not shown a blue or red background on the required fields if I open them or save them.10:47
udonoOr is an empty fields.Char != "" ?10:48
-!- bechamel(n=user@user-85-201-14-207.tvcablenet.be) has joined #tryton10:58
-!- bechamel(n=user@user-85-201-14-207.tvcablenet.be) has joined #tryton11:28
cedkI find two commits in OpenERP that can be usefull:11:39
cedkhttp://bazaar.launchpad.net/%7Eopenerp/openobject-server/trunk/revision/117011:39
cedkhttp://bazaar.launchpad.net/%7Eopenerp/openobject-server/trunk/revision/117211:39
cedkbut I don't know if we need it for the release11:40
cedkthe one for attachment is not mandatory for the release11:40
cedkbut the fix for copy field with translate=True, must perhaps been added for the release11:41
cedkwhat do you think?11:41
-!- bechamel(n=user@user-85-201-14-207.tvcablenet.be) has joined #tryton11:45
cedkbechamel: ping11:49
bechamelcedk: yes ?11:55
cedkbechamel: did you see my comments on the 2 commits from OpenERP?11:57
bechamelcedk: no11:58
cedkbechamel: ok I restart11:58
cedkhttp://bazaar.launchpad.net/%7Eopenerp/openobject-server/trunk/revision/117011:58
cedkhttp://bazaar.launchpad.net/%7Eopenerp/openobject-server/trunk/revision/117211:58
cedkbut I don't know if we need it for the release11:58
cedkbut the fix for copy field with translate=True, must perhaps been added for the release11:58
cedkbut the fix for copy field with translate=True, must perhaps been added for the release11:58
cedkwhat do you think?11:58
bechamelcedk: both are bugs, isn't it ?12:01
cedkbechamel: attachment is not really a bug, it is more a behavior12:03
bechamelcedk: yes12:04
bechamelcedk: but copy of translations is a bug12:05
cedkbechamel: yes12:07
cedkbechamel: I will integrate it12:07
-!- ikks(n=igor@190.12.153.202) has joined #tryton12:25
udonocedk: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?!12:37
cedkudono: do you know which problems?12:38
udonocedk: 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...12:43
udono...like this12:43
cedkudono: ok, it is not related to the fix12:44
cedkudono: but we fix this issue12:46
udonocedk: of course, nothing else expected ;-)12:47
cedkudono: I think I fixed when working at tiny12:48
-!- yangoon(n=mathiasb@p549F4954.dip.t-dialin.net) has joined #tryton13:02
CIA-14tryton: C?dric Krier <ced@b2ck.com> default * 1102:56d46031ed16 trytond/trytond/osv/orm.py: Fix copy records with field translatable13:07
cedkdo I make the fix for the access right on attachment ?13:07
bechamelcedk: 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.13:11
cedkbechamel: no with the webdav, the user that doesn't have access to a record, can not add an attachemtn13:13
cedkbechamel: we can see this fix like a security fix13:19
bechamelcedk: yes this is what i said later13:23
cedkbechamel: ok I will work on it13:24
cedkudono: for the issue436, is the title right ?13:51
cedkudono: or is there an other issue than the wizard size for user?13:51
udonooh yes, I mixt up two bugs... i correct them13:52
CIA-14tryton: 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.13:53
udonocedk: fixed, thanx13:54
CIA-14tryton: 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 issue43613:55
udonoQuestion: 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.13:55
CIA-14tryton: ced roundup * #436/Add user setup dialog is a way to small: [resolved] Fix with changeset 4b65801d40a013:55
cedkudono: because empty field will have the False value13:58
cedkudono: you must test bool(person_last_name)13:58
cedkudono: for the issue437, I don't understand the progressbar is small13:59
cedkudono: just 3 lines of comments and one animation13:59
CIA-14tryton: ced roundup * #437/The progressbar dialog is to big, it looks ugly: [chatting] Can you put a screenshot of the problem?14:01
udonocedk: ups, maybe it depends on my window preferences (save window size)? I test...14:02
cedkudono: put a screenshot14:03
udonocedk: no, It is my fault. I resized, and now it works.14:04
udonocedk: I close the bug14:04
CIA-14tryton: 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 ...14:06
udonocedk: Thaks for the test bool, it works good.14:10
cedkudono: just one remarks, you must be carefull with the call of set_size_request in the client15:44
cedkudono: because it make the widget less dynamic15:45
CIA-14tryton: C?dric Krier <ced@b2ck.com> default * 852:d12ca9f64d38 tryton/tryton/ (3 files in 2 dirs): Remove bad size_request15:51
CIA-14tryton: C?dric Krier <ced@b2ck.com> default * 1103:5b52307e79b3 trytond/trytond/ir/attachment.py:16:05
CIA-14tryton: Add check access for the res_model of attachments to use the access right of16:05
CIA-14tryton: the linked model (inspired by the OpenERP rev1172)16:05
CIA-14tryton: C?dric Krier <ced@b2ck.com> default * 1104:203cb8663367 trytond/trytond/osv/orm.py: Add context when calling check of ir.model.access16:05
CIA-14tryton: C?dric Krier <ced@b2ck.com> default * 1105:d66dfc6748c8 trytond/trytond/osv/orm.py: Fix get_eval for BrowseRecordNull16:05
cedkI fix the attachment access right16:14
cedkIt was a good idea to fix it for this release as I find some other bugs :-)16:15
CIA-14tryton: Udo Spallek <info@virtual-things.biz> default * 853:f13f910f6147 tryton/tryton/gui/main.py:17:27
CIA-14tryton: "Previous" entry is duplicated in file menu. Removed17:27
CIA-14tryton: hG: Enter commit message. Lines beginning with 'HG:' are removed.17:27
CIA-14tryton: C?dric Krier <ced@b2ck.com> default * 854:bc7f56732784 tryton/: merge17:27
CIA-14tryton: udo.spallek * r233 /wiki/DocumentationModules.wiki: Initial17:27
CIA-14tryton: cedric.krier@b2ck.com * r234 /wiki/DocumentationModules.wiki: Fix typo17:27
CIA-14tryton: cedric.krier@b2ck.com * r235 /wiki/DocumentationModules.wiki: Fix typo17:27
cedkTimitos, udono: can we talk about the module relationship?17:33
udonocedk, yes17:37
cedkI talk with bechamel and there is some divergent points17:38
udonook17:38
cedkwe think that the split of the name into first,last name is not really good17:38
cedkbecause it introcudes a lot of problems17:39
cedkhow to we display the name first + last or last + first17:39
cedksomes have more than just first and last name17:39
cedkcompany doesn't have two names17:39
cedketc...17:39
udonocompany has on name...17:39
cedkWe think that it is not as simple as we though when we make basic module17:40
cedkso there is any problem to add this functionnality with a module by inheritance17:40
cedklike relationship_multi_name ?17:41
udonono problem17:41
udonowe have the type defined, so we can divide the names like we want in an addon module.17:42
cedkudono: that is the next point17:42
udono:-)17:43
cedkwe are not sure about the usefull of the type separation17:43
cedkin fact not for the basic module17:44
cedkas any others module need this information (for now)17:44
udonocedk: thanb everything stays as it is?17:44
bechamelcedk: udono: whats the url of the repo again? i would like to re-read it17:45
cedkudono: no the split of email, website out of the address is good17:45
cedkbechamel: http://mercurial.intuxication.org/hg/relationship17:45
bechamelcedk: thx17:46
cedkudono: there is also the informal, internal flags17:46
cedkI don't see the usefull of this17:46
bechamelcedk: i was search in the /tryton/ list17:46
udonocedk: informal and internal can be removed17:46
cedkbechamel: it is not yet added17:47
cedkthere is also the relationship.party.legalform17:49
udonocedk: type separation is generic for a module about persons and organisations. You cant build any higer level without this decision...17:49
cedkI'm not sure for the name17:49
cedkudono: we don't need for any modules for now ?17:50
udonocedk: no, but it is a generic information if we are talking about persons or organisations.17:50
udonocedk: You cant say a module is for persons AND organisations, and dont build this decision in, I think17:52
bechamelthe 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)17:53
cedkudono: I don't understand17:53
udonocedk: I try to explain17:53
udonowhat we have now is mainly the tiny partner module17:54
udonothere we can create companys with addresses and persons connected to the addresses17:54
udonojust b2b is meaning ful for this model17:55
cedkudono: no, there is no person connected to the addresses17:55
udonocedk: Contact name?17:55
cedkudono: you can see that when you create a employee (person) it is linked to a party not an address17:55
cedkudono: contact name is for the addresse17:55
cedkudono: like "Building Block B"17:56
cedkudono: or for the name of the mailbox17:56
cedkudono: but not for a person of a company17:56
cedkwe don't reproduce the modelisation errors of tinyerp17:57
udonocedk::-)17:57
bechamelmaybe 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 system17:57
cedkonly the one that we know :-)17:57
cedkbechamel: I think it is more complicate17:58
bechamelcedk: yes, but imho the current modelisation is missing something17:59
cedkbechamel: what ?17:59
udonoafk17:59
bechamelcedk: the problems udono try to adress17:59
cedkthe fact that there is no difference between a company and a person18:00
cedk?18:00
bechamelcedk: name on party doesnt make sens for organisations not for people18:00
cedkbechamel: don't understand18:00
cedkorganisation has name and people has name18:02
bechamelcedk: 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 sense18:02
cedkbechamel: organisation can be a sub-organisation18:02
udonoback18:02
bechamelcedk: yes but it's another field18:02
cedkbut it is not needed for basic use18:03
cedkto make business with a company, you don't need to know his employee nor his companies18:04
cedkand to make business with people, you don't need to know where they work18:04
udonocedk: 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.18:05
cedkafk not for major business18:05
bechamelcedk: 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 situation18:05
udonobechamel: good idea, but18:05
cedkudono: no, because those account stuffs are used in the module18:06
cedkso it is not the same18:06
cedkbechamel: I'm not again the possibility to separate people and organisation but for me it is not mandatory for simple module18:07
udonobechamel: ... 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...18:07
cedkudono: this is because we need specific information about the current company18:08
cedkit is not need to modelise every things18:08
cedkfor accounting stuff, a person or an organisation are the same18:09
udonocedk: for me I am talking about generic design, not special implementation18:09
bechamelcedk: 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 delivery18:09
cedkas we have a platform that allow to extend easily models, we must keep module as simple as possible18:10
cedkbechamel: this is a ergonomic  question, and the solution will not be easy18:11
udonocedk: for me its way to simple like it is18:11
udonocedk: but just because of the company module...18:11
bechamelcedk: checkboxes like on the adresses are ok, no ?18:11
cedkbechamel: yes, but I think you talk about the possibility to just see invoice address on a partner form ?18:12
cedkudono: what is the problem of company module ?18:12
bechamelcedk: 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 etc18:13
udonocedk: since it uses inherits not inherit it doesent take care about extension modules of relationship18:14
udonocedk: replace the checkbox with a 0ne2many18:14
udonosorry bechamel: replace the checkbox with a 0ne2many18:14
cedkbechamel: but it depends on how a company works18:15
cedkbechamel: they can want to enforce which party can be supplier18:16
bechameludono: why a o2m ?18:16
cedkbechamel: and some doesn't want18:16
cedkbechamel: so if you put this constraint on the base module, it is not possible to have the other behavior18:16
udonobechamel: because an address can be for "shipment" and "invoice"18:16
cedkand once again this kind of constraint must be developped in a module18:17
bechamelcedk: the solution is to make default true on all checkbox, like that no filter by default18:17
cedkudono: we have one check box by type, so it is like a one2many but we find it more eyecandy in the address form18:17
bechameludono: there are several checkboxes, one by main "role"18:18
cedkbechamel: I don't talk about addresses18:18
cedkbechamel: I talk about party18:18
cedkbechamel: addresses are filtered with the right checkbox (except if there is a bug)18:18
bechamelcedk: 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 view18:20
cedkbechamel: which group ?18:20
bechamelcedk: a <group> in the view18:20
cedkit is really simple to write a little module that add this functionnality18:21
cedkbechamel: because what you talk about is just for supplier18:21
cedkbechamel: because you will not do the same for customrs18:22
bechamelcedk: and customers18:22
cedkbechamel: why will you prevent a company to sell to somebody ?18:22
bechamelcedk: it's to prevent mistakes18:23
cedkyou can write a module named "realtionship_supplier"18:23
cedkbechamel: mistake about what ?18:23
cedkall this will generated is that people will encode many times the same party because they don't find him18:24
cedkbecause it has not the right check box18:24
cedkas I say I understand that for somes it is usefull to have this behavior for supplier18:25
bechamelcedk: 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-versa18:25
cedkbut the best to handle this is by a module18:25
cedkbechamel: because they don't realise that you can have a party that is supplier and customer18:26
bechamelcedk: 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.party18:26
cedkand once again, it is just a simple module that I can write in 1 hour18:26
cedkand it has no sence to create this for customers18:27
cedkevery body can be customers18:27
bechamelcedk: not in most of the businesses18:27
cedkbechamel: give an example ?18:27
udonocedk: 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?18:27
bechamelcedk: i dont want to forbid it i just want to allow the user to filter results it's different18:28
cedkbechamel: you already have it, you write a function field that allows this18:28
cedkudono: I don't understand a one2many is more complicated than a checkbox18:29
udonocedk: but its everytime clean18:30
bechamelcedk: probably udono was talking about a m2m18:30
cedkbechamel: there is a view "Suppliers" so you can filter on supplier18:30
udonobechamel: yep, sorry18:30
cedkI need more examples18:31
cedkand there is still the categories field18:31
cedkbut with a many2many, it is more difficult to filter18:32
cedkif you want all the party that has "a" and "b"18:32
bechamelcedk: 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 there18:32
cedkwe can not handle this query18:32
bechamelcedk: which one ?18:33
cedkbechamel: but it is a simple module to add this18:33
cedkbechamel: don't understand18:33
bechamelcedk: which query is not handled ?18:34
udonocedk: examples: Implemetation for school: Teacher/Scholar/Parent/Administration/... for Healthcare: Patient/Nurse/Doctor/Insurance18:34
cedkbechamel: as search on many2many that have "a" and "b"18:34
bechamelcedk: aj ok18:35
udonocedk: dont understand?18:35
cedkand what I try to explain, is that with modularity, it is the freedom18:35
cedkas you can change anything18:35
cedkudono: so you have three category: "supplier", "customer", "other"18:36
udonocedk: :-)18:36
cedkudono: if you want to search for every party that are "supplier" and "customer"18:36
cedkudono: we can not make this with one search18:36
bechamelcedk: 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)18:36
cedkudono: so the client (GTK) can not make this query18:36
cedkudono: you can do it with programmation18:37
cedkbechamel: it works for only few queries18:37
cedkwhat I try to say, it is that we must stay very generic and let every possibilitty open in the basic modules18:38
cedkbecause we must let the possibility to modify it with other modules18:38
bechamelcedk: this gives the parties that have all the category whe are searching for18:38
cedkso if you implement a model that is too strict, you can not change it18:39
udonocedk: ok I understand18:39
cedkbechamel: yes it works for the query I say, but there is other query like that where it will not work18:39
udonocedk: but what about a module which is to simple to extend?18:39
cedkudono: I don't find an example18:40
udonocedk: what about my concerns about the company module?18:40
cedkudono: I don't understand the problem with company module18:40
bechameludono, cedk: let's talk about one feature at time and see if it's possible to do it in another module18:40
cedkbut can we stop for 20min the conversation, I need to go to the shop before it closes18:40
udonocedk: 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...18:41
bechamelcedk: i have to leave too18:41
udonobye18:41
cedkudono: but you can depend on company module18:41
cedkudono: and change it18:41
bechameludono, cedk: bye, and one can continue by mail18:42
CIA-14tryton: udo.spallek * r236 /wiki/DocumentationClient.wiki: Created wiki page through web user interface.18:42
udonocedk: But I like to change the party module and be sure that the changes are inherited by the other modules18:42
udonobechamel: see u18:43
bechameludono: bye18:43
udonocedk: http://www.tryton.org/~irclog/2008-08-11.log.html#t2008-08-11_08:0518:53
-!- X0d_of_N3d_(i=C-C_C-X@gateway/tor/x-c51547db75e12efc) has joined #tryton18:56
cedkback19:03
cedkudono: there is many possibilities for the issue you can find19:04
cedkudono: one will be to have default value that works for company19:04
cedkudono: an other one is to depend on company and add the necessary code on company model19:04
udonocedk: 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...19:07
udonocedk: last point is the namespace of the "relationship" module, wich actually doesnt do anything about "relationships" its just 'party'19:08
udonocedk: I know its a boring job to rewrite namespaces...19:08
udonocedk: but for me pre release is the last possible chance to do...19:09
cedkudono: I think also about that19:10
cedkudono: and I don't see the problem19:10
cedkudono: for me the module is about the relationship between the company and others19:10
udonocedk: 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...19:14
udonocedk: The module doesent implement any relationships TO other modules, its a generic party module19:14
cedkudono: CRM is a subset because it about customers19:14
cedkudono: but will be extended to add stuff19:15
udonocedk: Yes, my plannings are not CRM its RM generic relationship management...19:15
udonocedk: more over its relationship planning and /management19:16
cedkudono: what you emplemenent is relationship between party, but here the simple module is just relation between the company and others19:17
cedkudono: and the category is for specification of the relation19:18
udonocedk: the actual relationship module doesn't provide any infrastructure for relationship. It just provide Infrastructure for party. Even the own enterprise is a party.19:18
cedkudono: it is the base19:19
udonocedk: category is not relationship, its just information about informational roles.19:19
cedkudono: but you aggre that your module just extend the party19:24
udonocedk: yes, after your clearing that company is extendable, I just like to have a very simple party module.19:25
udonocedk: for me the address and contact part could go in another module, too.19:25
udonocedk: and just a single name, no internal, no informal checkbox19:25
cedkwait, if you go like that we will make one module per model19:26
udonocedk: one module per generic model. Its like account and account_invoice for me...19:27
cedkudono: in account_invoice there is invoice.line, payment_term ...19:27
-!- ikks(n=igor@190.12.153.202) has joined #tryton19:27
udonocedk: yes, and?19:28
udonocedk: 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...19:29
udonos/is/if/19:29
cedkudono: like ?19:30
udonocedk: Read page 47 to 58...19:31
udonocedk: 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...19:32
udonocedk: but its equal, both ways are possible: address inside party and outside party. More clean is outside party.19:33
udonocedk: another thing we can put in an alternate module is relationship.party.legalform aka the old party type...19:36
cedkudono: but it is the facility can work with addresses, it is not incompatible19:37
udonocedk: 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.19:40
cedkudono: I don't say use the addresses for this19:40
cedkudono: you can add an other model to handle this19:40
cedkand if you think about hospital, you must have all the rooms inside the system and just select one19:42
udonocedk: 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...19:45
cedkudono: it is true that we can remove the relationship.party.type model19:50
cedkudono: and I think that we sould use the name_get function to display the party name in reports like invoice, etc...19:51
cedkinstade of using name19:51
cedkit will allow easier implementation of extended modules19:51
cedkand add the contact mecanism for email, website, phone, ...19:52
udonocedk: and what about namespace party? (since we need to rewrite all other modules because of name_get?)19:52
udonocedk: add contact mechanism means addon module?19:52
cedkudono: yes contact machanism can be on other module19:54
udonocedk: ok, no problem, good decision19:54
cedkudono: for the name, I don't know19:55
udonocedk: Is it the dump work to realise?19:57
udonocedk: I help!19:57
cedkudono: no, it is the fact that this module will be the base for any CRM implementation19:57
cedkudono: or any other stuf linked to relation19:57
udonocedk: 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.19:59
cedkudono: yes, but menu structure will be confusing20:00
udonocedk: why?20:00
udonocedk: CRM and "Customer" partys are different things20:01
cedkudono: but it is all about relationship20:01
udonocedk: the first is for the changeing relationships and the second is for the standing data20:02
udonocedk: party is just a base for relationships, but not the same20:02
cedkudono: for me it is the first step20:03
udonocedk: of course its a first step, its the _base_ for relationships, but it is not the same then relationships. This is what I mean.20:04
cedkudono: we can change the description in __tryton__.py20:05
cedkudono: but I think that the namespacefor Party must be relationship.party20:05
udonoif party is the base, than it must be party.relationship...20:06
udonobut it actually did nt do any relationship...20:06
cedkno because we will have relationship.relation, relationship.role, ...20:06
udonoACTION despair20:07
cedkand what about the menu ?20:07
udonocedk: we will have party.relationship, party.role20:07
udonoMenu is "Party" or "Parties"20:08
udono...since we have divided out People and Organisation ...20:08
udonoMenu for Relationships is "Relationship"20:09
udono... when we have it20:10
udonoWhy not take some small concepts and namespaces from Silverston?20:13
cedkACTION need to think20:18
udonoHe 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?_e20:23
udonoubmissionDateDescending http://www.amazon.de/review/product/0471380237/ref=cm_cr_dp_all_helpful/275-7110011-8755911?_encoding=UTF8&coliid=&showViewpoints=1&colid=&sortBy=bySubmissionDateDescending20:23
udonoAnd its an external reference...20:23
cedkudono: let think about it for the WE20:29
cedkudono: we will see monday20:29
udonocedk: no problem20:32
udonoafk20:40
-!- Gedd(n=ged@77.109.115.165) has joined #tryton20:49
-!- igor__(n=igor@190.12.153.202) has joined #tryton21:32
CIA-14tryton: udo.spallek * r237 /wiki/DocumentationClient.wiki: Edited wiki page through web user interface.22:29
CIA-14tryton: udo.spallek * r238 /wiki/DocumentationClient.wiki: Edited wiki page through web user interface.22:29
-!- ovnicraft(n=ovnicraf@190.154.63.122) has left #tryton23:54

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!