IRC logs of #tryton for Thursday, 2013-08-22 #tryton log beginning Thu Aug 22 00:00:02 CEST 2013
jerojasrohi all. I have a problem with trytond detecting new modules; I installed both trytond and the trytond_account modules via pip, but the new module (account) doesn't show up in the module list that the client (tryton) shows to me00:10
jerojasrorestarting trytond doesn't make any difference00:11
jerojasrohowever, right after connecting with the client, the trytond log shows the following:00:12
jerojasro[Wed Aug 21 22:09:37 2013] INFO:modules:account:registering classes00:12
jerojasrobut I still don't get an up-to-date module list00:12
jerojasroany hints on what might I be doing wrong?00:12
jerojasroI've noticed the --init=all option in trytond, and after issuing a trytond -c  ... -d mydatabase --init=all the modules do appear00:23
jerojasrobut, am I expected to do that each time I install a new module?00:24
sisalp2jerojasro: which version ?00:40
sisalp2jerojasro: there was a bug about this. Updating any module by any means solved the problem00:41
sisalp2jerojasro: may still be there00:41
jerojasrosisalp2: 2.802:49
jerojasrotryton and trytond 2.8, account 2.8.102:49
jerojasrosisalp2: also, what do you mean by "Updating" ? pip install -U ? --force-reinstall ?02:51
-!- priyankarani(~priyanka@ has left #tryton09:19
-!- dfr( has left #tryton10:53
readyliebe mitchatter von puls.. danke für die freundschaft zuihm... sein pc wird heute abend für immer off gehen. hagen ist vor zwei wochen leider verstorben :(14:52
jvblascoIs there any way to iterate all model registers without doing a search for every posible register in the table? something like "carriers = Pool().get('carrier'); for carrier in carriers:"17:56
pokolijvblasco: carriers = Pool().get('carrier').search([])17:59
jvblascopokoli: Thnx18:01
jvblascopokoli: I guess from your statement that "carriers =[])" would return the list of all carriers records, wouldn't it?18:56
pokolijvblasco: yes if cls it's an instance of carrier model18:57
pokolijvblasco: can I ask for the use case?18:57
jvblascopokoli: cause i always get the same error when executing it:
jvblascopokoli: im trying to search for all carriers that are available for a delivery. I need to ask the backend b4 making any decission in my customer e-commerce platform18:59
pokolijvblasco: so why you don't have a available field and filter by this field?19:00
pokolijvblasco: for the traceback the code of modules/carrier_grid/", line 79, in get_available_carriers would be usefull to help :P19:00
jvblascopokoli: cause i need to calculate if the carrier can make the delivery for a received postal code19:00
jvblascopokoli: yeah, that's the method i'm trying to implement.19:01
pokolijvblasco: would you mind pasting the code of the function to another pastebin?19:01
jvblascopokoli: sure
jvblascopokoli: check_available right now returns true for each call19:03
pokolijvblasco: how you are calling it, directly from rpc?19:05
jvblascopokoli: they are methods intended to accessed from my customers e-commerce modules19:06
jvblascopokoli: intended to be*19:06
jvblascopokoli: I assumed that calling a method from the rpc interface wouldn't change the behaviour19:08
-!- vcardon( has left #tryton19:09
pokolijvblasco: I cannot ensure it as I don't know, have you tried calling it from inside tryton platform?19:11
jvblascopokoli: nope19:12
pokolijvblasco: I can not see anything strange in the code19:12
pokolijvblasco: maybe something with nested transactions, are you starting a new transaction?19:13
jvblascopokoli: i think it's a context issue cause cache_ctx = context.copy() is the last one in the stack trace19:13
jvblascopokoli: but i need to provide the context when i make the call in the remote code19:14
jvblascogimme a sec to generate the paste bin19:14
pokolijvblasco: calling it from php?19:14
pokolijvblasco: I think that the issue is on the context initialitzation, as context is a list and must be a dict19:14
jvblascothat's the php code which i'm using to make the call19:15
pokolijvblasco: $context is an associative array?19:16
pokolijvblasco: see previous comment19:16
jvblascopokoli: yeah19:16
jvblascopokoli: in fact this is what i can see in the server debug19:16
jvblascopokoli: i mean those are the params the server is receiving in the RPC call19:18
pokolijvblasco: I understood. One moment I will validate if context is correct :P19:18
pokolijvblasco: if you fix the context is not correct, as you have a list, then the context inside, and another empty context19:20
jvblascopokoli: what do u mean?19:21
pokolijvblasco: that's what i seee directly from the client
pokolijvblasco: i'm printing the context on the same line you have the error19:21
pokolijvblasco: the important part is the ( starting your context19:21
pokolijvblasco: and this part on the end , [46025]) {}19:22
jvblascopokoli: so the server thinks 46025 is part of the context too?19:22
pokolijvblasco: you're passing the context and another array with 46025 in it19:23
pokolijvblasco: ahh I see 46025 is the postal code no? So the problem is with the postal code19:23
pokolijvblasco: in line 19 you have a TRUE param you don't have in the second request. May be this is the problem19:24
jvblascopokoli: gimme a sec to try19:24
jvblascopokoli: solved. The problem was that the context is the last parameter u need to pass through a RPC call, or so it seems19:50
jvblascopokoli: $request = $connection->sendRequest('model.carrier.get_available_carriers', array($uid, $token, array(46025), $context)); solved everything. Note that $context is now the last parameter.19:50
plantianWill proteus behave the same if used with just xmlrpc instead of with trytond as a module?21:57
cedkplantian: normally21:58
cjbarnes18hi cedk, could you tell me what I have missed on 92001? Maybe I have used the incorrect terminology?22:01
cedkcjbarnes18: I don't understand22:03
cjbarnes18cedk: on issue 92001 Add wsgi protocol, I have use wrapper code (maybe this shaould be called a factory function) to provide the jsonrpc_app, you suggested this was wrong22:05
cedkcjbarnes18: I think it is not a nice design22:06
cjbarnes18ok, great.22:06
cedkcjbarnes18: probably a callable class is better22:07
cjbarnes18ok, I was considering that anyway.22:07
cedkcjbarnes18: and probably it should be singleton with error if instanciated many times22:08
cedkcjbarnes18: and to be complete it must support the GET method for sao22:09
cjbarnes18I have been looking at GET, not sure where to start yet.22:10
cjbarnes18why a singleton?22:10
cjbarnes18for multiprocess I guess singlton would not be a problem tho...22:12
cjbarnes18ACTION pings cedk22:16
cedkcjbarnes18: because pool can not be started more than once22:43
cedkcjbarnes18: and configuration is also global22:43
cjbarnes18cedk: ok, I will work to these designs, thank you very much for your time.23:13

Generated by 2.11.0 by Marius Gedminas - find it at!