IRC logs of #tryton for Friday, 2009-01-30 #tryton log beginning Fri Jan 30 00:00:02 CET 2009
CIA-10tryton: C?dric Krier <> default * 1172:08e20f298ca5 tryton/tryton/gui/ Add logout before backup database for issue76300:06
CIA-10tryton: ced roundup * #763/Exception: AccessDenied: [resolved] Fix with changeset 08e20f298ca500:07
X0d_of_N0dudono: you around?00:22
udonoX0d_of_N0d: yes, but short00:26
X0d_of_N0dI got the ldap test connection thing working00:29
udonoX0d_of_N0d: Yeah great!00:29
X0d_of_N0dI think there are some other things we could do to make it better, but I'd like to move forward with what we've got00:30
X0d_of_N0dfirst though, the module can't be called "ldap"00:31
X0d_of_N0dthe repo should be moved to something like ldap_base00:31
X0d_of_N0dor whatever00:31
X0d_of_N0dotherwise it overlaps the ldap module itself and breaks everything00:32
udonoX0d_of_N0d: ok,  understand and agree.00:35
udonoX0d_of_N0d: But Iam to tired for more, I'll test it tomorrow.00:36
X0d_of_N0dok, I pushed my changes00:36
X0d_of_N0dI'll wait for you to move the repo before I do anything else00:36
udonoX0d_of_N0d: yes00:36
X0d_of_N0dcatch you tomorrow then00:36
udonoX0d_of_N0d: where to move the repo?00:36
udonoX0d_of_N0d: ldap_base00:37
udonoX0d_of_N0d: see you, good night00:39
X0d_of_N0dudono: night man, see you later00:39
vengfulsquirrelAre domains used for validation purposes or just to filter selections?01:01
cedkvengfulsquirrel: both01:03
vengfulsquirrelcedk: Okay with respect to the location type checking it sure would be easier if the type couldn't be changed after creation because there are a multitude of things that need to be checked to guarantee that domains are maintained.01:05
vengfulsquirrelIt doesn't seem like just checking for moves be enough.01:06
vengfulsquirrel*will be01:06
cedkvengfulsquirrel: for me, it is enough to add a domain on locations in stock.move01:08
cedkvengfulsquirrel: and add a constraint on stock.location to check if no move are already created for location of type "view" and "warehouse"01:08
CIA-10tryton: vengfulsquirrel roundup * #760/View Location Type: Restrict views in stock.move and PackingInternal in stock.packing.01:19
CIA-10tryton: vengfulsquirrel roundup * #760/View Location Type: Added check for moves to stock.location.01:20
CIA-10tryton: vengfulsquirrel roundup * #760/View Location Type: Added type view to stock.location check.01:21
vengfulsquirrelMaybe there is a better way to upload those rather than send them one at a time.01:21
cedkvengfulsquirrel: could you just create one patch per functionnality01:24
cedkvengfulsquirrel: as it is your first patches, I think it is better that you just copy/paste the diff of your work for review before creating a patch01:25
cedkvengfulsquirrel: and an other remarks, try to not let ending space01:26
cedkvengfulsquirrel: here for your patches, I prefer to have only to patch files: one for check on warehouse and one that add view type01:27
vengfulsquirrelDo you mean trailing space on a line ?01:28
cedkvengfulsquirrel: yes01:28
cedkvengfulsquirrel: is it ok for you?01:30
cedkvengfulsquirrel: I go to sleep01:38
vengfulsquirrelcedk: Okay, yeah I have to learn all the hg options, i'll ttyt.01:38
cedkvengfulsquirrel: for diff: hg diff01:38
vengfulsquirrelYeah but now I need to diff across a revision.01:38
-!- ikks(i=igor@ has joined #tryton03:02
-!- ikks(i=igor@ has joined #tryton04:30
-!- yangoon( has joined #tryton05:18
-!- vengfulsquirrel1( has joined #tryton07:28
-!- paola( has joined #tryton07:35
-!- nicoe( has joined #tryton07:45
-!- paola( has joined #tryton08:09
CIA-10tryton: vengfulsquirrel roundup * #760/View Location Type: diff -r 5e68bcf0fcbf -r 2a9aa85c4a2f --- a/ Wed Jan 28 14:28:41 2009 -0800 +++ b/ Thu Jan 29 16:10:0 ...08:10
-!- Gedd( has joined #tryton08:16
-!- sharkcz( has joined #tryton08:24
CIA-10tryton: vengfulsquirrel roundup * #760/View Location Type: diff -r 2369cf53348a --- a/ Thu Jan 29 23:12:09 2009 -0800 +++ b/ Thu Jan 29 23:22:44 2009 -0800 @@ ...08:26
-!- vengfulsquirrel1( has left #tryton08:27
-!- Timitos(n=Timitos@ has joined #tryton09:01
-!- enlightx(n=enlightx@ has joined #tryton10:00
-!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton10:13
cedkudono: I just read a little the code of ldap_base10:28
cedkudono: and in the on_change function you define: vals={}10:29
cedkudono: this is not a good practice because {} will be a global instance10:29
cedkudono: and by the way, you use it for the return value, this is also bad because normally you must not change the value given in argument10:30
cedkudono: this kind be linked to the strange behavior explain in on_change_anon_bind10:31
udonocedk: yes, thanks. But what if vals == None ?10:31
udonovals is None=10:31
cedkudono: the framework will always put value in vals10:31
cedkudono: the default signature is: on_change_xxx(self, cursor, user, ids, vals, context=None)10:32
cedkudono: by the way, this is why we set context=None and not context={}10:32
cedkudono: because it can become a memory leak in long run10:33
udonocedk: Ok, thanks a lot, I never mentioned that this could be a problem...10:34
cedkudono: one more remarks, I will raise an exception in the TestServerConnection wizard to have translated message error10:34
udonocedk: where? why?10:35
-!- bechamel(n=user@ has joined #tryton10:36
cedkudono: you fill a response with english string, I will raise an exception to have the message translated10:36
cedkudono: or better a warning, but it is not yet implemented on wizard10:37
udonocedk: I see... hmm I need to use babels _()?10:38
cedkudono: no10:39
udonocedk: hmm, but then the translation isn't in the xx_XX.csv10:39
cedkudono: look at _error_messages10:39
cedkudono: Babel is only for the client10:40
cedkudono: we don't use gettext on the server side because there is some issue with multi-threading10:40
-!- carlos(n=carlos@ has joined #tryton10:41
udonocedk: ok, I get it.10:42
udonocedk: Thanks a lot, I will repair this tonight.10:43
udonocedk: but I cannot use this on a wizzard?10:43
udonocedk: or I cannot use warning on a wizard?10:44
cedkudono: you can use the raise_user_error function but not the raise_user_warning10:44
udonocedk: Yes, thanks a lot.10:47
cedksome good points, and some others less10:58
bechamelcedk: what are the less good points ?11:10
cedkbechamel: good: point 2, 3, 411:11
udonobechamel: cedk, for me is 1. one of the best points.11:38
cedkudono: so it depends of what he want to say11:39
cedkudono: if he speak about computing to prepare data to be display in web browser, I agree11:40
-!- ikks(i=igor@ has joined #tryton11:40
bechameludono: there are 3 argument in point 111:41
cedkudono: but if it is to put some important computing stuff on client side, I think you can not fully trust the result from the client11:41
cedkudono: and of course it depends of the use of the software11:47
-!- johbo( has joined #tryton11:53
udonobechamel: these are the three arguments for me:12:01
udono1. Web applications encourage a thin-client approach12:01
udono>> Tryton client is neither a thin client like a Browser nor a fat one like adempierre. Tryton client provides the 'good' architectures from both worlds.12:01
udono2. Concentrating computing power in the datacenter is fine if you're a Google or a Microsoft, but that approach puts a lot of pressure on smaller players.12:01
udonoTryton can be setup as a single user app without a problem. Furthermore it can easyly extended with more separate user machines12:01
udono3. security vulnerabilities abound in networked applications, and the complexity of the browser itself seemingly makes bugs inevitable12:01
udonoTryton is a network application. We need to take all the care about vulerabilities like all other. But IE or Firefox are very popular apps so it will take some time if someone writes a virus/keylogger/troyan for tryton...12:01
-!- Gedd( has joined #tryton12:01
cedkudono: one big issue with browser today is cross-site vulnerability that Tryton have not12:04
bechameludono: security becomes a problem when your server is world reachable and imo an erp should be restricted to the company intranet12:05
cedkbechamel: but for a webbase application, it can be only local that it can be breaks with cross-site scripting12:06
bechamelcedk: yes, but even if you can get credential with xss, you are stuck as long as you cannot reach the server12:07
cedkbechamel: but you can infect the webbrowser of a use (when he browse the internet) and retreive information when he is connected to the local webserver12:09
cedkbechamel: this is in the point 512:14
cedkbechamel: best security is the disable browser :-)12:14
bechamelcedk: yes, finaly all points are good points :)12:15
cedkbechamel: yes but perhaps not enough explain12:16
udonocedk: bechamel, Yes, I agree.12:24
udonobechamel: as I told on our last meeting when you showed me your prototype webclient: Its enough to show and see data on the web. There is no need for manipulating data over a browser...12:25
udonoBTW Richard stallman had some general concerns in the guardian about 'cloud computing', too.12:26
cedkudono: web client is not yet cloud computing :-)12:27
bechameludono: yes but access to data (even readonly data) is already a security problem12:27
-!- ikks(i=igor@ has joined #tryton12:48
carlosI'm late for the discussion, but for a SaS deployment or an internal deployment of Tryton with many clients, having to update all those clients one by one once the server is upgraded is a bit... madness. In this case a web client is the best option. However, if the Tryton's client is able to update itself (once the user confirms it) when a newer server version is detected, then the web client is not so useful anymore13:13
bechamelcarlos: yes auto update would be great, like ... firefox :)13:15
carlosbechamel: hmmm, well, something like firefox, only if the new client is able to talk with new and older protocols of Tryton13:16
carlosotherwise, it should depend on the server it connects13:16
cedkI realy hate those kind of auto upgrade feature13:17
cedkin big structure, you don't upgrade software without any rules13:18
cedkand most of the time the user don't have admin access to install software13:18
carloscedk: well, I'm not talking about checking for upgrades against but against a server in your company so it's easier to do upgrades13:18
cedkin windows environment, you can put the single exe on a shared folder and everybody use the same exe13:19
cedkand if you get linux client, it is simple to write a script that upgrade packages on demand13:19
cedkor better just use a terminal server if you don't want to manage many OS's13:22
carloswell, I agree that those options may work in many use cases, but for SaS deployments, that's not so easy13:22
cedkcarlos: do you really think that a big company will use SAS for his ERP ?13:23
carlosIn those cases, you don't control the client computers at all, but you may want to deploy bug fixes to your customers13:24
carloscedk: well, not at all13:24
carlosbut small medium companies will do (that's quite usual in Spain right now)13:24
carlosso everytime there is a security / bug fix13:24
cedkcarlos: as you say in SAS you don't control the client computer so you can not push upgrade13:24
carlosthat's why adding a way to upgrade the client automatically on connection time is a good thing13:25
carlosor at least warn the user that there is an upgrade13:25
cedkcarlos: so automatical upgrade breaks distribution package13:25
carloswell, that's why I said that at least, you should warn the user13:26
cedkcarlos: and for windows people, it will be possible13:27
carlosif it's not a distribution package, you can do the upgrade like in Windows13:27
carlosif it's a distribution package, you may provide package upgrades too13:27
cedkthe only option, I see it is to put a little icon that says there is a new version of the client for the same branch13:27
carlosthat's what I mean, you need a way to notify the user about the upgrade, and they choose to upgrade or not (or an admin may configure it to be automatically updated, but that's a user call)13:29
carlosalso, I don't know if this is possible without many problems from the development point of view13:29
cedkcarlos: only a notify is possible but no more13:30
carlosdo you think is possible to have a Tryton client that is able to speak with a 1.0 server and a 1.2 server at the same time?13:30
carlosso depending on the server you connect to, it uses the 1.0 or the 1.2 protocol?13:30
cedkcarlos: we disallow this13:30
cedkcarlos: it is not only a matter of protocol but also of features and behavior13:31
carlosI suspected something like that13:31
cedkthere is no garantee that the stuff will still work correctly13:31
cedkcarlos: we put a check in the client to not allow connecting to a server with a different branch13:32
carlosI know about that, I was just wondering about having such feature in the client, so it can speak with both servers and behave in a different way depending on the server version13:33
cedkcarlos: this will put a big overload in the client13:34
carlosI see13:34
yangoon  what are you meaning by SAS?13:35
carlosyangoon: Software as a Service13:36
carloswhen you charge a monthly fee for hosting Tryton's server and handle its Internet connection, backups and security updates13:37
yangooncarlos: thx, because there exists a SAS Deployment Wizard and the name is a registered trade mark13:38
carlosI guess that's why OpenERP uses 'ondemand' to refer to such service:
cedkcarlos: by the way, informing users about security update can be made with email13:42
carlosI guess..13:44
-!- Gedd( has joined #tryton13:58
-!- enlightx( has joined #tryton13:59
CIA-10tryton: matb roundup * #762/KeyError: 'customer_location': [chatting] @bch: Thx for your input! It is really a little bit strange, but the problem was now just gone without any further chnage to the databa ...14:26
-!- ikks(n=igor@ has joined #tryton14:32
CIA-10tryton: matb roundup * #761/Stock: Partially assigned packing does not appear under Assigned Packings: No, I didn't try to delete the packing, but the inventory move(s). Trying to do the same once again I experienced the following behaviour: Assign ...14:44
-!- jporcel( has joined #tryton14:48
jporcelhi there14:48
jporcelI'm interested on contribute somehow, I can translate into spanish, catalan and code something if required14:49
jporcel;-) see you14:49
jporcel(the above is only jabber no mail)14:49
-!- jporcel( has left #tryton14:49
CIA-10tryton: ced roundup * #761/Stock: Partially assigned packing does not appear under Assigned Packings: Sorry but I'm pretty sure that you try to remove the packing. Do you type <CTRL>+d ?15:07
-!- cristi_an(i=5978d3ce@gateway/web/ajax/ has joined #tryton17:20
-!- simahawk( has joined #tryton17:23
-!- vengfulsquirrel( has joined #tryton17:31
-!- tekknokrat( has joined #tryton17:36
-!- paola( has joined #tryton17:50
-!- tekknokrat( has left #tryton17:58
-!- enlightx( has joined #tryton18:38
-!- juanfer(n=juanfer@ has joined #tryton20:35
-!- vengfulsquirrel( has joined #tryton20:43
-!- Gedd( has joined #tryton20:51
vengfulsquirrelIs there a problem with calling function fields from within a _constraints check method ?21:12
vengfulsquirrel*not calling I mean referencing21:12
-!- paola_( has joined #tryton21:57
cedkvengfulsquirrel: don't understand, give an example22:31
vengfulsquirrelcedk:  I'd like to call line.location in create_move instead of line.get_location(...) .  Are function fields not for internal use and more for the view to use ?23:00
-!- carlos(n=carlos@ has joined #tryton23:06
-!- yangoon( has joined #tryton23:06
-!- panthera( has joined #tryton23:06
vengfulsquirrelcedk: I made a bunch of changes to the stock module so that I could extend it correctly maybe if you are interested in seeing those I can paste all the diffs into another ticket, if anything just to see examples of problems that could arise when extending it.23:08

Generated by 2.11.0 by Marius Gedminas - find it at!