IRC logs of #tryton for Tuesday, 2010-08-10

chat.freenode.net #tryton log beginning Tue Aug 10 00:00:02 CEST 2010
-!- zodman(~Miranda@67.223.236.231) has joined #tryton00:01
-!- ebanders(~ebanders@c-66-41-121-0.hsd1.mn.comcast.net) has joined #tryton00:18
-!- FWiesing(~FWiesing@85-126-100-130.work.xdsl-line.inode.at) has joined #tryton00:18
-!- dba(~daniel@static.88-198-196-34.clients.your-server.de) has joined #tryton00:18
-!- sejo(~SeJo@exherbo/developer/sejo) has joined #tryton00:18
-!- masterhumper(~SeJo@exherbo/developer/sejo) has joined #tryton00:20
-!- tekknokrat(~lila@p579FB7A9.dip.t-dialin.net) has joined #tryton00:27
-!- pheller(~pheller@2002:ad30:d8c3:0:fa1e:dfff:fee6:aabf) has joined #tryton01:24
-!- pheller(~pheller@2002:ad30:d8c3:0:fa1e:dfff:fee6:aabf) has left #tryton01:24
-!- digitalsatori(~tony@116.233.249.147) has joined #tryton03:09
-!- ikks(~ikks@190.158.116.213) has joined #tryton03:37
-!- zodman(~zodman@foresight/developer/zodman) has joined #tryton04:02
zodmaney dudes04:33
zodman /home/zodman/Desarrollo/try/trytond/trytond/security.py(78)check()04:33
zodman-> raise Exception('NotLogged')04:33
zodmani run trytond -u <module> -d <mydb>04:33
zodmanbut when i click on gtk client04:34
zodmantrytond gime that error04:34
zodmanhow can i prevent04:34
zodmanit ?04:34
zodmani need killit04:34
-!- zodman(~zodman@foresight/developer/zodman) has joined #tryton05:39
-!- mr_amit(~amit@117.254.178.13) has joined #tryton06:09
-!- udono(~udono@dynamic-unidsl-85-197-24-16.westend.de) has joined #tryton07:20
-!- hoRn(~chatzilla@dslb-094-223-211-094.pools.arcor-ip.net) has joined #tryton07:23
hoRnGood morning07:24
-!- Timitos(~kp@88.217.184.172) has joined #tryton07:24
hoRncedk: time for a little interview?07:25
-!- johbo(~joh@statdsl-085-016-072-173.ewe-ip-backbone.de) has joined #tryton07:28
cedkhoRn: I have no much time08:16
hoRnok08:16
cedkhoRn: what do you want?08:16
hoRnsometimes a small idea of your thinkings about mrp08:16
hoRncedk: i'll contact you later08:17
cedkhoRn: use mailing list08:20
hoRncedk: ok08:20
-!- ecarreras(~under@unaffiliated/ecarreras) has joined #tryton08:43
-!- paepke(~paepke@p4FEB625C.dip.t-dialin.net) has joined #tryton08:48
-!- enlightx(~enlightx@static-217-133-61-144.clienti.tiscali.it) has joined #tryton09:05
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton09:10
-!- eLBati(~elbati@94.164.116.137) has joined #tryton09:31
-!- digitalsatori(~tony@116.233.249.147) has joined #tryton10:14
digitalsatoricedk: does tryton have access control on field10:16
-!- johbo(~joh@statdsl-085-016-072-173.ewe-ip-backbone.de) has joined #tryton10:26
-!- Timitos(~kp@88.217.184.172) has joined #tryton10:42
cedkdigitalsatori: no10:47
cedkdigitalsatori: we did not see yet any usage of it that justify the overload10:48
digitalsatoriit will be very cool if you can implement this10:48
cedkdigitalsatori: what is the usage?10:50
cedkdigitalsatori: by the way, we will not accept an implementation like in OE (I think it is the worst thing they have done recently)10:51
digitalsatoriin openerp, the field with readonly attribute will not allow the changed value to be save to the server10:51
digitalsatoriwhat about tryton10:51
cedkdigitalsatori: it is the same10:52
digitalsatorithen, some times I need a field to be readonly to certain groups ,how could do that10:53
digitalsatoriI don't want to hide the field10:53
cedkdigitalsatori:  no more explaination10:53
digitalsatoriI can't find a good way to do the above mentioned in OE10:54
digitalsatorias openerp don't really have a full access control on field10:55
digitalsatoriit only hide or unhide field for groups10:55
digitalsatoricedk, what do you mean about 'no more explaination'?10:57
cedkdigitalsatori: I mean I need more explaination about the business logic10:58
digitalsatoriIt is not hard to understand, for example, I want value in price field can only be changed by people in sales manager group while other people remain readonly11:01
digitalsatorior I want a field to be readonly to all people but the value can be changeed by on-change event11:03
digitalsatoriif you can CRUD access on field will make those kind of senario very easy to handle11:05
digitalsatoriIf not, at least have readonly attribue on view level will ease many effort for developer11:06
-!- jahc(~jahc@ip-118-90-78-92.xdsl.xnet.co.nz) has joined #tryton11:09
jahcyo. :)11:09
jahcI'm checking out Tryton11:10
jahcI'm reading docs atm.. but standby for newbie questions soon if I cant figure this out. :)11:10
cedkdigitalsatori: I will simply override write/create of the record and put there the access control11:14
paepkejahc, welcome here.11:15
paepkecedk, are there already ideas for an audit trail module? to track changes a user mades to the datasets?11:16
cedkpaepke: there is the history functionality11:16
jahcso if I understand this right, you run trytond first to run the server.. and then you run the client to access it?11:17
digitalsatoricedk: yeah currently we do the same, but I thought a access control on field will make things easy and flexible11:17
cedkdigitalsatori: I'm not sure it is simplier11:18
paepkecedk, yes, the history module. i already saw this. but it wouldn't it be kind of slow if it is widely used?11:18
digitalsatoristill the way you mentioned, can't not set a field to be SEEN as readonly11:19
paepkejahc, yes, its a client-server system. you could try out neso which is a standalone version.11:19
jahcok. is it the same, functionality wise?11:20
paepkejahc, yes.11:20
jahcok.11:20
jahcbut,. I have installed all the files on my system.. I'd like to try and get that going if I can..11:20
paepkejahc, you can use the client and server on the same system, too of course.11:21
jahctrytond fails with the message socket.error errno 98 address already in use .. but I'm not sure what parameters it takes11:21
cedkdigitalsatori: you can set it as readonly but I think your design is wrong because a stored value should not depend on the user reading/writing it like that11:22
jahcthat was in the function self.socket.bind((interface, port))11:22
cedkpaepke: of course it slow down the system but it is like any auditing tool11:22
paepkecedk, for an audit trail i don't need access to the history data in the real system. i assume for tracking changes it would be better to do this somewhere else.11:23
cedkpaepke: and at least it is just run a SQL query for each UPDATE queries11:23
paepkecedk, doesn't it has a more complex query when accessing models with enabled history?11:24
jahcnm. I'll do as you suggested and use neso.11:25
cedkpaepke: no if you don't ask to read at a specific date11:26
paepkejahc, what processes do you have in use on youre machine? maybe another process is blocking the ports for trytond.11:26
digitalsatori:cedk, this is the part I could'nt understand, would you mind explain more, How could set a field disply as read-only, while the value still can be changed by code and saved to server11:26
jahcits pretty much a standard ubuntu install on my netbook.11:26
paepkecedk, ic. good design. slowing down only on update is ok. an additional logger like for audit trail would do kind of the same.11:27
jahcneso appears to be working. thanks guys. :)11:27
cedkjahc: there is just this http://bugs.tryton.org/roundup/issue164411:28
paepkejahc, good luck. its a good starting point. for production i would use trytond.11:28
-!- Red15(~red15@unaffiliated/red15) has joined #tryton11:28
jahcah, yes. but this is just for research for school. :)11:28
cedkdigitalsatori: for me you must have two fields:11:28
cedkdigitalsatori: - one function field that gives you the default value11:28
jahcstudying C#.net diploma.. we're investigating some open source software to make up one solution for an IT problem11:29
cedkdigitalsatori: - one that store the value for users who can11:29
cedkdigitalsatori: so you display one of those two fields depending of the user11:29
paepkejahc, you know that tryton is written in python?11:30
digitalsatoricedk: thank you very much for your enlightment, so the function field will showing as readonly for unauthorize person11:31
cedkdigitalsatori: yes but I still think that your design is strange11:32
digitalsatoricedk: I explained my senario11:32
digitalsatoricedk: is it logical to set the price field readonly to normal sales agent while allowing the manager have the updae access right11:33
jahcpaepke: yes.11:33
jahcand built on top of postgresql11:34
jahcsounds very cool11:34
jahcthis part of my study is related to team work, and currently we're all researching things that are not necessarily related to our studies..11:34
jahcif that makes sense. :)11:34
cedkdigitalsatori: so what if one sale edited by the manager, is later opened by a normal sale ?11:35
digitalsatoricedk: no difference, the normal sale can see the order line but the price is still readonly11:36
cedkdigitalsatori: but which price will he see? The modified one from manager or the standard?11:37
cedkdigitalsatori: I think your issue if not linked to edition but more on workflow11:38
digitalsatoricedk: of course, the modified one, the purpose is don't allow the normal sales have the right to change the price11:38
cedkdigitalsatori: like a normal sale can not validate a sale with price different from the standard price11:38
cedkdigitalsatori: but if the normal sale re-select the product he will have the standard price and the price of the manager is lost11:39
cedkdigitalsatori: other way, is you set it readonly for normal sale and override create/write to set the standard price if the user is normal sale11:40
digitalsatoricedk: the logical is that the normal sale is only allow to issue an order with standard price, if the customer need the price adjustment, it will elevated to the manager to handle11:41
digitalsatoricedk: basicly these senario means that the normal sale has only read access on price field, while the manager has CUD control on price field11:42
jahcsee you guys.11:43
cedkdigitalsatori: I think the good solution, is normal sale can only validate sale only if price is standard one11:44
digitalsatoricedk, not exactly he can still validate the order after manager change the price11:45
digitalsatoricedk, he can see the changed price as he has the read access right, but he can't change the price, sorry if I make you confuse11:47
cedkdigitalsatori: any way, an access control on field will not change the issue because you don't know if the value write comes from default or from user11:48
cedkdigitalsatori: the only way is to write code on create/write that validate the creation/modification11:49
cedkdigitalsatori: and let the field no readonly11:49
digitalsatoricedk: hehe, yeah, for current moment,11:50
cedkdigitalsatori: you can not do an other way11:51
digitalsatoricedk: what about implemting a readonly or editable attribute on view level11:53
cedkdigitalsatori: it will not fix your issue11:54
cedkdigitalsatori: and it is already there11:54
digitalsatoricedk: the current readonly attribut on vim xml is not realy on view level11:54
digitalsatoricedk: as it will block the value change as well11:55
cedkdigitalsatori: don't understand11:56
digitalsatoricedk: readonly on view level means that the user can't change the value, but the running code can change the value and save it to server11:56
cedkdigitalsatori: this is a wrong design11:57
cedkdigitalsatori: the server doesn't know if the value written is good or not11:58
cedkdigitalsatori: the field must be readonly and filled on the server side12:03
digitalsatoricedk: what I'm saying is not conflict with the current definition of readonly field12:04
digitalsatoricedk: what I need is not a readonly field, it  is un-readonly field but seeing as readonly on the view to certain users12:05
cedkdigitalsatori: you said that the client must send the readonly fields but how could you trust this values12:05
digitalsatoricedk: I can totally understand logical of current readonly field12:06
cedkdigitalsatori: but you want that the price for normal sale is sent to the server12:08
digitalsatoricedk: yes, the price field should not be a readonly field, as manager has the ability to change the price and save it to the server, but the normal user will see it readonly12:09
cedkdigitalsatori: but how do you want it to be filled?12:10
digitalsatoricedk: with the default price if manager don't change the price12:11
cedkdigitalsatori: that comes from where?12:13
digitalsatoricedk: from the code, let say the onchange event setting on product_id12:14
cedkdigitalsatori: which code ? What I try to show you is that you will say "from the client" but it could not be trusted12:15
digitalsatoricedk:  instead, I'm saying actually from server12:16
cedkdigitalsatori: and how do you want that the server know what to do without writing code12:17
digitalsatoricedk: I'm not saying that server will do without writing code12:20
cedkdigitalsatori: so for me the best way is: make the field readonly dynamicly and write code in create/write to drop price value if the user has not right12:21
digitalsatoricedk: how could I set the field readonly dynamicly12:22
cedkdigitalsatori: with PYSON12:24
cedkhttp://doc.tryton.org/1.6/trytond/doc/topics/pyson.html12:24
digitalsatoricedk: thank you very much for your patient, I will study it12:25
cedkdigitalsatori: this kind of behavior must always be written twice one on the server and one on the client12:27
-!- enlightx(~enlightx@static-217-133-61-144.clienti.tiscali.it) has joined #tryton13:59
-!- woakas(~woakas@pcsp163-59.supercabletv.net.co) has joined #tryton14:36
-!- digitalsatori(~tony@116.233.249.147) has joined #tryton14:50
cedkdigitalsatori: by the way, i think your devs could be a standard module14:54
-!- pheller(~pheller@c1fw231.constantcontact.com) has joined #tryton14:57
-!- enlightx(~enlightx@dynamic-adsl-94-34-172-6.clienti.tiscali.it) has joined #tryton15:10
-!- digitalsatori(~tony@116.233.249.147) has joined #tryton16:06
-!- enlightx(~enlightx@dynamic-adsl-94-34-172-6.clienti.tiscali.it) has joined #tryton18:06
-!- paepke(~paepke@p4FEB2682.dip0.t-ipconnect.de) has joined #tryton18:21
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton18:31
-!- paepke(~paepke@p4FEB2682.dip0.t-ipconnect.de) has left #tryton19:14
-!- plantian(~ian@c-69-181-194-95.hsd1.ca.comcast.net) has joined #tryton19:24
-!- ecarreras(~under@unaffiliated/ecarreras) has joined #tryton19:42
-!- eLBati(~elbati@94.166.48.255) has joined #tryton20:42
-!- gremly(~gremly@190.26.157.133) has joined #tryton23:02
-!- tekoholic(~quassel@174-29-136-8.hlrn.qwest.net) has joined #tryton23:18

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