| chat.freenode.net #tryton log beginning Thu Aug 26 00:00:02 CEST 2010 | ||
| 2010-08-26 01:00 -!- Hydrant(~aj@unaffiliated/hydrant) has joined #tryton | ||
| 2010-08-26 01:00 <Hydrant> I'm not sure I'm a fan of the fact trytond.conf is world-readable by default in my install | ||
| 2010-08-26 01:20 -!- sharoon(~sharoon@vpn21.its.manchester.ac.uk) has joined #tryton | ||
| 2010-08-26 01:36 -!- gremly(~gremly@190.147.153.138) has joined #tryton | ||
| 2010-08-26 02:08 -!- gremly(~gremly@190.147.153.138) has joined #tryton | ||
| 2010-08-26 02:16 -!- pheller(~pheller@2002:ad30:d8c3:0:fa1e:dfff:fee6:aabf) has joined #tryton | ||
| 2010-08-26 02:47 -!- digitalsatori(~tony@116.233.243.167) has joined #tryton | ||
| 2010-08-26 03:05 -!- ikks(~ikks@190.158.116.172) has joined #tryton | ||
| 2010-08-26 03:26 -!- woakas(~woakas@pcsp163-59.supercabletv.net.co) has joined #tryton | ||
| 2010-08-26 03:50 -!- digitalsatori(~tony@116.233.243.167) has joined #tryton | ||
| 2010-08-26 04:06 -!- gremly(~gremly@190.26.186.242) has joined #tryton | ||
| 2010-08-26 05:19 -!- yangoon(~mathiasb@p549F7189.dip.t-dialin.net) has joined #tryton | ||
| 2010-08-26 08:05 -!- evernichon(~evernicho@mailout.fief.ch) has joined #tryton | ||
| 2010-08-26 08:25 -!- eLBati(~elbati@94.165.1.168) has joined #tryton | ||
| 2010-08-26 08:46 -!- Okko(~Okko@62.58.29.41) has joined #tryton | ||
| 2010-08-26 09:00 -!- paepke(~paepke@p4FEB6299.dip.t-dialin.net) has joined #tryton | ||
| 2010-08-26 09:14 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton | ||
| 2010-08-26 09:44 -!- enlightx(~enlightx@host198-217-dynamic.14-87-r.retail.telecomitalia.it) has joined #tryton | ||
| 2010-08-26 09:59 -!- bechamel(~user@chimie-prtx11.scf.fundp.ac.be) has joined #tryton | ||
| 2010-08-26 10:18 <paepke> good morning cedk. i'm currently evolving a attachment backend based on a nosql database. I have two concepts. the easy one: just replacing the get_data and set_date functions. And the hard one: introducing a new StorageModel which won't be compatible with the sql one. | ||
| 2010-08-26 10:19 <paepke> cedk, i've found no other dependencies on the attachments like joins or using that data model directly, except the webdav.py | ||
| 2010-08-26 10:19 <paepke> cedk, do you have any suggestions or something i didn't get already? | ||
| 2010-08-26 10:24 <bechamel> paepke: your goal is to replace the filesystem with a nosql db for the attachements or to provide a new backend that will replace postrgesql ? | ||
| 2010-08-26 10:25 <paepke> bechamel, thats the question. i want to replace the attachment system and that is build on filesystem and postgresql. it would be better to have all data in nosql. not only the file. | ||
| 2010-08-26 10:26 <paepke> bechamel, but i don't wanna write a backend to replace other modules with a sql backend like party or product. | ||
| 2010-08-26 10:26 <bechamel> paepke: ok | ||
| 2010-08-26 10:32 <bechamel> paepke: nothing prevent you to implement the easy solution and after extend it | ||
| 2010-08-26 10:38 <paepke> bechamel, yes, youre right. | ||
| 2010-08-26 10:39 <bechamel> IMO the difficult par of a "ModelNoSQL" that would replace ModelSQL is the search method | ||
| 2010-08-26 10:39 <bechamel> paepke: btw wich nosql db do you plan to use ? | ||
| 2010-08-26 10:40 <paepke> bechamel, i wanna use couchdb, as i have a specific problem, which can't be done using mongodb. | ||
| 2010-08-26 10:40 <paepke> bechamel, thats not tryton related :-) | ||
| 2010-08-26 10:43 <bechamel> actually the biggest problem, with those db is the lack of concurency support (or at least the different approach) | ||
| 2010-08-26 10:44 <paepke> bechamel, its not a bug, its a feature | ||
| 2010-08-26 10:45 <paepke> but you are right. you have to deal with sync-problems if there are two conflicting edits. | ||
| 2010-08-26 10:46 <paepke> imo replacing the ModelSQL in the whole system doesn't make sense. at least not for the current modules. | ||
| 2010-08-26 10:47 <paepke> nevertheless its perfect replacement for the attachment module. | ||
| 2010-08-26 10:47 <bechamel> paepke: also what happens in case of a hardware failure when an attachement is saved ? is there any journal to cleann stuff after the failure ? this would be a regression compared to the fs storage | ||
| 2010-08-26 10:50 <paepke> bechamel, if its not written you did not get back an "ok" | ||
| 2010-08-26 10:55 -!- Red15(~red15@unaffiliated/red15) has joined #tryton | ||
| 2010-08-26 10:56 <yangoon> paepke: what are the principle advantages from nosql oder fs? better search? | ||
| 2010-08-26 10:57 <yangoon> s/oder/over/ | ||
| 2010-08-26 10:59 <paepke> yangoon, better replication (based on document fields), better search could be. not investigated. | ||
| 2010-08-26 11:01 <yangoon> paepke: so you are developing it just for the replication advantage? | ||
| 2010-08-26 11:01 <paepke> yangoon, no, not only. | ||
| 2010-08-26 11:03 <paepke> yangoon, replication: i have a use case where files were stored in a web application which runs outside the customers network to give access to his customers. they can upload files for themselves. | ||
| 2010-08-26 11:04 <paepke> yangoon, the customer wants that the files will be magically available in both systems. local tryton and remote web application. but of course not every file. | ||
| 2010-08-26 11:05 <paepke> yangoon, thats were the field based replication comes into account. | ||
| 2010-08-26 11:06 <paepke> where.... | ||
| 2010-08-26 11:06 <yangoon> paepke: and the web app uses already nosql db? | ||
| 2010-08-26 11:08 <paepke> yangoon, no. | ||
| 2010-08-26 11:08 <paepke> yangoon, but its prepared. | ||
| 2010-08-26 11:10 <yangoon> paepke: it is an interesting issue, just to check: which detail is preventing to use a connector to tryton instead rewriting the attachment system? | ||
| 2010-08-26 11:13 <paepke> yangoon, its an unreliable connection, pulling from the web is not usable (firewalling issues). and couchdb has the solution for both problems. | ||
| 2010-08-26 11:15 <yangoon> paepke: IC, thx | ||
| 2010-08-26 11:15 <paepke> yangoon, anyway its not easy to replicate filesystem based storage to other nodes. cluster filesystems were not funny to use. thats a lot easier with such a document based storage. | ||
| 2010-08-26 11:16 <paepke> yangoon, especially if you only use read/write/search on the files. | ||
| 2010-08-26 11:16 <yangoon> paepke: if you need replication, then yes | ||
| 2010-08-26 11:16 <paepke> yangoon, its even a multi-master setup. documents can be uploaded via the local customer site and the web-application. | ||
| 2010-08-26 11:17 <paepke> yangoon, so my idea was to use couchdb to modify the attachment part and have all my problems solved by it. | ||
| 2010-08-26 11:17 <paepke> yangoon, hopefully | ||
| 2010-08-26 11:18 <yangoon> paepke: and get some new problems...;) | ||
| 2010-08-26 11:18 <paepke> yangoon, i try to prevent this :-) | ||
| 2010-08-26 11:18 <paepke> yangoon, and its an interesting projectg | ||
| 2010-08-26 11:18 <yangoon> paepke: I see the concurrenc problem, as bechamel already said | ||
| 2010-08-26 11:21 <paepke> yangoon, why? please explain | ||
| 2010-08-26 11:23 <yangoon> paepke it depends on the layout: if you allow to write documents from local network as well as from the web app, documents could be updated simultaneously on both sides | ||
| 2010-08-26 11:26 <paepke> yes, you have to take care of such a problem. that is by design. | ||
| 2010-08-26 11:29 <paepke> for a local deployment (not my veryspecific use case) you can use kind of a master/slave layout. where you limit the writes to only one master and use continious replication to the slaves where you read. | ||
| 2010-08-26 11:30 <bechamel> iirc chouchdb save the both version of the document and flag them as duplicates | ||
| 2010-08-26 11:31 <paepke> bechamel, yes. thats right. | ||
| 2010-08-26 11:31 <paepke> so its up to the application to solve this kind of issue | ||
| 2010-08-26 11:32 <paepke> even its just a popup to the user | ||
| 2010-08-26 11:37 <paepke> are there somewhere attachments used i didn't get already? only attachment module itself and webdav? | ||
| 2010-08-26 11:43 -!- sharoon(~sharoon@vpn21.its.manchester.ac.uk) has joined #tryton | ||
| 2010-08-26 11:46 <cedk> paepke: I don't see any advantage for using NoSQL instead of filesystem | ||
| 2010-08-26 11:48 <paepke> cedk, scalability. | ||
| 2010-08-26 11:49 <cedk> paepke: you can have the same with filesystem | ||
| 2010-08-26 11:49 <paepke> cedk, not that easy. using a clusterfs is horrible | ||
| 2010-08-26 11:49 <cedk> paepke: by the way, what do you name scaliablity | ||
| 2010-08-26 11:52 <bechamel> paepke: how many documents do you plan to store ? | ||
| 2010-08-26 11:52 <paepke> cedk, scalability in terms of storage space which could exceed one node. | ||
| 2010-08-26 11:52 <paepke> bechamel, currently not that much. as i stated above i have the problem with the replication. | ||
| 2010-08-26 11:53 <cedk> paepke: this is easy to fix as you can see Tryton stores document with a tree structure so you can move one or many folder in an other place | ||
| 2010-08-26 11:54 <cedk> paepke: you can do replication with rsync/unison etc. | ||
| 2010-08-26 11:54 <paepke> cedk, i know how the files were stored in tryton. | ||
| 2010-08-26 11:54 <paepke> cedk, i need the replication based on a field in the application like a boolean "do publish" | ||
| 2010-08-26 11:55 <paepke> cedk, and i have the multi-master situation. | ||
| 2010-08-26 11:56 <cedk> paepke: so NoSQL will not help you | ||
| 2010-08-26 11:56 <paepke> anyway. i see the document based database as a filesystem on steroids. for example appending additional fields on it | ||
| 2010-08-26 11:56 <paepke> cedk, why don't you think it will not help me? | ||
| 2010-08-26 11:57 <cedk> paepke: because it doesn't solve your issue | ||
| 2010-08-26 11:57 <cedk> paepke: which is an issue that have no clean solution | ||
| 2010-08-26 11:59 <bechamel> paepke: does both sites works on the same documents ? or each site just generates their documents ? | ||
| 2010-08-26 11:59 <paepke> cedk, i know its not that easy what i'm planning to do. | ||
| 2010-08-26 12:00 <paepke> cedk, generate their documents. but the should appear on both sides. | ||
| 2010-08-26 12:00 <paepke> bechamel... | ||
| 2010-08-26 12:00 <paepke> bechamel, think of a upload-download portal. | ||
| 2010-08-26 12:02 <cedk> paepke: why not having only one source | ||
| 2010-08-26 12:02 <bechamel> so what about add a bollean field (like to_be_synced) on the attachement table and when the connection is up between the sites, just send the flagged documents ? | ||
| 2010-08-26 12:02 <paepke> cedk, anyway. isn't nosql an additional storage engine which can live next to filesystem based storage? is see it like having an additonal sql database. postgre fits the needs pretty good. but mysql is out there, too | ||
| 2010-08-26 12:03 <cedk> NoSQL is not an additional SQL database | ||
| 2010-08-26 12:03 <paepke> cedk, cause there is an slow unreliable connection between the webserver and the tryton base. | ||
| 2010-08-26 12:05 <paepke> bechamel, i have to take care of the uploaded documents, too on the other side. i have to develop an additional functions which take care of all replication which could happen (broken connection, is there already a version, ...) which is all integrated in couchdb. | ||
| 2010-08-26 12:06 <paepke> cedk, yes,NoSQL its not SQL. i see it as a "competitor" to file based storage. of course not to SQL | ||
| 2010-08-26 12:06 <paepke> cedk, sorry for the misleading use of words. | ||
| 2010-08-26 12:07 <cedk> paepke: in fact I think you must not have colision, just use an append only scenario | ||
| 2010-08-26 12:07 <yangoon> "nosql" (the community now translates it mostly with "not only sql") ;) | ||
| 2010-08-26 12:07 <cedk> yangoon: the current filesystem mechanism is a NoSQL | ||
| 2010-08-26 12:10 <paepke> cedk, so why not supporting an additional NoSQL storage next to the current file system storage? | ||
| 2010-08-26 12:11 <cedk> paepke: but I don't see the purpose | ||
| 2010-08-26 12:11 <paepke> is there an purpose to have mysql next to postgres? | ||
| 2010-08-26 12:13 <cedk> paepke: they are both SQL server | ||
| 2010-08-26 12:14 <cedk> paepke: NoSQL is not a standard | ||
| 2010-08-26 12:14 <cedk> paepke: so how can you make a generic behavior | ||
| 2010-08-26 12:15 <paepke> cedk, I know that NoSQL is a broad range methods of storing information. | ||
| 2010-08-26 12:16 <paepke> cedk, i'm primary talking about schemaless document storage, which is provided by mongodb or couchdb. I assumed its clear as we speak about storing files. my appologies for that. | ||
| 2010-08-26 12:18 <bechamel> paepke: IMO the "broken connection" is not a big problem, just put a try-except and retry later (or just forget it if the document upload is in a cron), the "there is already a version" can be 1) ignored (the document is just overwirtten) 2) taken into account: the incoming document is stored appart and the user is asked to compare them (something you need to handle anyway) and choose the good one | ||
| 2010-08-26 12:19 <paepke> cedk, additionally (not my primary goal of this discussion)is one of the interesting features of having a couchdb storag is the possibility to take the documents with you just by cloning the couchdb to youre notebook. | ||
| 2010-08-26 12:22 -!- eLBati(~elbati@94.167.7.222) has joined #tryton | ||
| 2010-08-26 12:22 <paepke> bechamel, yes, thats a good point with using the cron. that were my first ideas about that project. | ||
| 2010-08-26 12:23 <paepke> bechamel, but after my studies, i remembered couchdb as a solution. and now i'm discussing here my ideas :-) | ||
| 2010-08-26 12:26 <paepke> bechamel, and its still one of my options. | ||
| 2010-08-26 12:27 <bechamel> the main advantage I see for couchdb is that it's distributed | ||
| 2010-08-26 12:32 <bechamel> but I read the couchdb doc and it seems that what they call distributed is actually replicated, I talk about distributed="one set of document that span several computers" (sharding?) | ||
| 2010-08-26 12:32 <paepke> bechamel, sharding is possible, too. | ||
| 2010-08-26 12:32 <bechamel> paepke: ok | ||
| 2010-08-26 12:35 <paepke> bechamel, see http://guide.couchdb.org/editions/1/en/clustering.html | ||
| 2010-08-26 12:43 <paepke> cedk, bechamel. I summarize my options: using a traditional approach writing a cron-script (non-blocking to the save of the attachment) which replicates the file to the other host and vice versa. | ||
| 2010-08-26 12:44 <paepke> cedk, bechamel: an additional option would be to use for example couchdb as backend for attachment which make the replication automagically, but needs the modification of core components of tryton. | ||
| 2010-08-26 12:45 <bechamel> just thinking out loud: with the current fs solution it would be possible to replace top-level local directory with mount point and thus "shard" the documents | ||
| 2010-08-26 12:46 <paepke> cedk, you don't see any advantages having multiple backends for file storage. like having multiple backends for sql storage? | ||
| 2010-08-26 12:47 <paepke> bechamel, yes, you are right with that sharding on top of mount points. it would even work on windows. | ||
| 2010-08-26 12:48 <yangoon> bechamel: I think your proposal is a very monolithic "shard" | ||
| 2010-08-26 12:49 <bechamel> yangoon: hence the quotes :) | ||
| 2010-08-26 12:49 <paepke> yangoon, bechamel: with couchdb you could shard at field level. for example based on save date, model, whatever. to have kind of multi-tier storage which slower machines on old data. | ||
| 2010-08-26 12:50 <yangoon> bechamel: understood :) | ||
| 2010-08-26 12:52 <cedk> paepke: you can have any fs you want | ||
| 2010-08-26 12:53 <cedk> paepke: fs is a standard protocol | ||
| 2010-08-26 13:10 <paepke> just for the completeness. there is GridFS, a FUSE Backend for Storing attachments inside mongodb. | ||
| 2010-08-26 13:16 -!- Okko(~Okko@62.58.29.41) has joined #tryton | ||
| 2010-08-26 14:12 -!- digitalsatori(~tony@116.233.249.146) has joined #tryton | ||
| 2010-08-26 14:53 -!- tony_(~tony@116.233.242.53) has joined #tryton | ||
| 2010-08-26 15:20 -!- tony__(~tony@116.233.242.0) has joined #tryton | ||
| 2010-08-26 15:40 -!- digitalsatori(~tony@116.233.240.110) has joined #tryton | ||
| 2010-08-26 15:53 -!- digitalsatori(~tony@116.233.240.110) has joined #tryton | ||
| 2010-08-26 16:00 -!- pepeu(~manuel@201.155.193.192) has joined #tryton | ||
| 2010-08-26 16:01 -!- tony_(~tony@116.233.245.238) has joined #tryton | ||
| 2010-08-26 16:20 -!- pheller(~pheller@c1fw234.constantcontact.com) has joined #tryton | ||
| 2010-08-26 16:34 -!- tony__(~tony@116.233.244.109) has joined #tryton | ||
| 2010-08-26 16:43 -!- paepke(~paepke@p4FEB07FC.dip0.t-ipconnect.de) has joined #tryton | ||
| 2010-08-26 16:44 -!- digitalsatori(~tony@116.233.243.197) has joined #tryton | ||
| 2010-08-26 16:54 -!- cheche1(cheche@188.85.213.151) has joined #tryton | ||
| 2010-08-26 17:13 -!- digitalsatori(~tony@116.233.243.197) has joined #tryton | ||
| 2010-08-26 17:22 -!- zodman(~Miranda@200.76.52.125) has joined #tryton | ||
| 2010-08-26 17:33 -!- sharoon(~sharoon@vpn21.its.manchester.ac.uk) has joined #tryton | ||
| 2010-08-26 18:30 -!- gremly(~gremly@190.147.153.138) has joined #tryton | ||
| 2010-08-26 19:05 -!- eLBati(~elbati@94.166.11.169) has joined #tryton | ||
| 2010-08-26 19:19 -!- sharoon(~sharoon@vpn85.its.manchester.ac.uk) has joined #tryton | ||
| 2010-08-26 19:35 -!- enlightx(~enlightx@dynamic-adsl-94-34-211-122.clienti.tiscali.it) has joined #tryton | ||
| 2010-08-26 19:47 -!- paepke(~paepke@p4FEB07FC.dip0.t-ipconnect.de) has left #tryton | ||
| 2010-08-26 19:54 -!- hoRn(~chatzilla@dslb-094-223-211-094.pools.arcor-ip.net) has joined #tryton | ||
| 2010-08-26 19:55 <hoRn> hi all | ||
| 2010-08-26 19:56 <hoRn> im struggling for hours with a small problem | ||
| 2010-08-26 19:57 <hoRn> (overall my learning is fast ; ) | ||
| 2010-08-26 19:59 <hoRn> i have a model with a many2one-field. this model has a workflow with a lot of states. | ||
| 2010-08-26 20:00 <hoRn> in the first state nothing of the many2one-related model is required, but after changing to a following state i want to set some of them required | ||
| 2010-08-26 20:02 <hoRn> can anybody give me a hint, how to do this: now i raise a user error in a function assigned to the workflow transition, but the user need to serch the required fields in the view | ||
| 2010-08-26 20:25 <enlightx> hoRn: what about "attrs"? you can set the required flag to true by object state | ||
| 2010-08-26 20:27 <hoRn> ok - i will take another search ;) | ||
| 2010-08-26 20:36 -!- enlightx(~enlightx@dynamic-adsl-94-34-211-122.clienti.tiscali.it) has joined #tryton | ||
| 2010-08-26 20:57 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton | ||
| 2010-08-26 21:04 <sharoon> enlightx: there is no attrs in tryton | ||
| 2010-08-26 21:05 <enlightx> sharoon: whoops...wrong channel ;-) | ||
| 2010-08-26 21:05 <sharoon> hoRn: refer http://hg.tryton.org/hgwebdir.cgi/1.6/modules/account/file/6532a3521264/account.py#l333 | ||
| 2010-08-26 21:06 <hoRn> i'll take a look | ||
| 2010-08-26 21:06 <sharoon> hoRn: You have to write PYSON expression for what you want | ||
| 2010-08-26 21:07 <sharoon> hoRn: refer http://doc.tryton.org/1.6/trytond/doc/topics/pyson.html | ||
| 2010-08-26 21:07 <hoRn> yes i know | ||
| 2010-08-26 21:07 <sharoon> hoRn: that will help you write the PYSON syntax | ||
| 2010-08-26 21:08 <hoRn> but the problem is a little bit more confused | ||
| 2010-08-26 21:08 <hoRn> for example: in sale you can put lines | ||
| 2010-08-26 21:08 <sharoon> hoRn: please explain, | ||
| 2010-08-26 21:09 <hoRn> sharoon: the line has his own definition of required fields - for example the pricel | ||
| 2010-08-26 21:10 <hoRn> you can not save a sale.line, if no price is set | ||
| 2010-08-26 21:10 <sharoon> hoRn: ok | ||
| 2010-08-26 21:10 <hoRn> sharoon: now think in your own sales.opportunities | ||
| 2010-08-26 21:11 <hoRn> you have fields in sale.opportunities - required or not | ||
| 2010-08-26 21:11 <hoRn> the lines are products - with defined requirements | ||
| 2010-08-26 21:11 <hoRn> nothing goes wrong | ||
| 2010-08-26 21:11 <sharoon> ok | ||
| 2010-08-26 21:12 <hoRn> but i will do this: a model similar to sales.oportunities | ||
| 2010-08-26 21:13 <hoRn> but i do not put products as lines, i have a own model | ||
| 2010-08-26 21:13 <hoRn> a hugh form with thausend of inputs | ||
| 2010-08-26 21:13 <sharoon> hoRn: please use pastie for pasting your code, might be easier to understand the problem | ||
| 2010-08-26 21:14 <hoRn> if the customer calls the first time, the telefonist ask something | ||
| 2010-08-26 21:15 <hoRn> after this the form needs completion, before he can convert it to a state like opportunity | ||
| 2010-08-26 21:16 <hoRn> but the telefonist need to save the result of the first call - the completion of the lines is only needed, if the parent-object will be converted to another state | ||
| 2010-08-26 21:17 <hoRn> sharoon: i will paste | ||
| 2010-08-26 21:20 <hoRn> http://pastie.org/1118644 | ||
| 2010-08-26 21:21 <hoRn> at line 225 is a strange try of doing that what i want | ||
| 2010-08-26 21:26 <hoRn> when i convert teh coatingrequest to an opportunity, i will check, if the coatingrequest.lines are filled in a minimal manner | ||
| 2010-08-26 21:27 <hoRn> finally it could be broken by design ;( | ||
| 2010-08-26 21:34 <sharoon> hoRn: first of all it is advised to use browse in the code rather than read (unless not avoidable) | ||
| 2010-08-26 21:35 <hoRn> ok | ||
| 2010-08-26 21:35 <sharoon> hoRn: line 244 etc are not pythonic at all | ||
| 2010-08-26 21:36 <hoRn> that was only a short idea - | ||
| 2010-08-26 21:38 <hoRn> sharoon: a short test - written in php ;) | ||
| 2010-08-26 21:40 <sharoon> hoRn: what is the problem u r facing? | ||
| 2010-08-26 21:41 <hoRn> sharoon: i was lookin for a possibility to set fields required in the lines if the 'parent' changes the state | ||
| 2010-08-26 21:42 <sharoon> hoRn: http://hg.tryton.org/hgwebdir.cgi/1.6/modules/sale/file/0b436b131d56/sale.py#l961 | ||
| 2010-08-26 21:44 <hoRn> sharoon: can i do a pyson statement against the value of a _parent.xxx field? | ||
| 2010-08-26 21:44 <sharoon> hoRn: yes | ||
| 2010-08-26 21:44 <sharoon> hoRn: like http://hg.tryton.org/hgwebdir.cgi/1.6/modules/sale/file/0b436b131d56/sale.py#l963 | ||
| 2010-08-26 21:46 <hoRn> hoRn: f.. - i tried this before - with no luck. i will go to do another attempt | ||
| 2010-08-26 21:48 <hoRn> sharoon: 'required': Equall(Eval('_parent_sale.party'),'someone') ? | ||
| 2010-08-26 21:53 <sharoon> hoRn: should work | ||
| 2010-08-26 21:53 <hoRn> sharoon: ok - thank you - i will give it a try | ||
| 2010-08-26 21:55 <sharoon> hoRn: if u need to see how client treats it, check record.py in tryton/gui/window/view_form/model | ||
| 2010-08-26 21:55 <hoRn> sharoon: ok | ||
| 2010-08-26 21:55 -!- Okko(~Okko@dhcp-077-251-140-095.chello.nl) has joined #tryton | ||
| 2010-08-26 22:09 <hoRn> sharron: i don#t get it - to tired ; thanks so long | ||
| 2010-08-26 22:15 <sharoon> hoRn: http://hg.tryton.org/hgwebdir.cgi/1.6/tryton/file/628d9539e86c/tryton/gui/window/view_form/model/record.py#l347 | ||
| 2010-08-26 22:17 <hoRn> :/ | ||
| 2010-08-26 22:18 <hoRn> sharoon: a last try - than beer | ||
| 2010-08-26 22:18 <sharoon> hoRn: good luck | ||
| 2010-08-26 22:18 <hoRn> sharoon: thnaks | ||
| 2010-08-26 22:32 -!- zodman(~zodman@foresight/developer/zodman) has joined #tryton | ||
| 2010-08-26 22:35 -!- Okko(~Okko@dhcp-077-251-140-095.chello.nl) has joined #tryton | ||
| 2010-08-26 22:49 -!- bechamel(~user@2001:6f8:3aa:0:1e4b:d6ff:fe60:a002) has joined #tryton | ||
| 2010-08-26 22:57 <zodman> dudes tryton development is easy !!!! | ||
| 2010-08-26 22:57 <zodman> xD | ||
| 2010-08-26 22:57 <zodman> good work! | ||
| 2010-08-26 23:28 -!- sharoon(~sharoon@vpn59.its.manchester.ac.uk) has joined #tryton | ||
| 2010-08-26 23:40 -!- pheller(~pheller@2002:ad30:d8c3:0:fa1e:dfff:fee6:aabf) has joined #tryton |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!