IRC logs of #tryton for Sunday, 2008-12-14 #tryton log beginning Sun Dec 14 00:00:02 CET 2008
-!- X0d_of_N0d( has joined #tryton00:06
-!- vengfulsquirrel( has joined #tryton01:05
-!- ikks(n=igor@ has joined #tryton03:40
-!- juanfer(n=juanfer@ has joined #tryton04:54
-!- yangoon( has joined #tryton05:19
-!- carlos( has joined #tryton09:27
-!- ChanServ(ChanServ@services.) has joined #tryton09:44
-!- bacule( has joined #tryton09:44
-!- panthera( has joined #tryton09:45
-!- Timitos(n=Timitos@ has joined #tryton10:02
-!- carlos( has joined #tryton10:07
-!- Gedd( has joined #tryton10:15
-!- udono( has joined #tryton11:02
-!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton12:11
-!- sharkcz( has joined #tryton12:50
CIA-53tryton: matb roundup * #423/operator: contains behaves strange with underscores: [chatting] 11.12.08 on IRC: (19:36:07) bechamel: yangoon: there is a little subtlety with "word begins", actualy the exact wording should be "cont ...15:07
-!- sharkcz( has joined #tryton15:09
-!- bechamel(n=user@ has joined #tryton15:25
-!- rvalyi(i=564b0b39@gateway/web/ajax/ has joined #tryton16:10
rvalyiHI guys, I'm playing with a Ruby on Rails backed by OpenERP server proto, but now I'm facing hard tradeoffs, anyone interrested?16:11
CIA-53tryton: udono roundup * #674/Modules: Userside switching language doesn't work any longer: [new] case: Create new database, default language= english. login and switch users language preference to german. Close the client, restart the s ...16:14
udonorvalyi: Hi, interested in what?16:15
rvalyiudono: discussing what are the best tradeoffs16:15
rvalyiBascially, I'm attempting to have Active Resource exposing the OpenERP server objects, that's a first step16:16
udonorvalyi: sorry, I don't understand what your aim is.16:17
rvalyibut when trying to back ActiveRecord by OpenERP server XML/RPC requests, I'm facing challenges: either forget the association/joins, either plug to the DB+XML/RPC for comuted fields but that woul mean working around the OpenERP security rules16:17
rvalyiudono: I'm making a proto of a Rails Application where you could instanly have the OpenERP (or Tryton) data model loaded16:18
rvalyiso you would code a Rails application (ecommerce, CMS, whatever) that woul be backed by OpenERP16:18
udonorvalyi: sounds like another client application?16:19
rvalyiit's like an other eTiny if you like16:19
udonorvalyi: ok.16:19
udonorvalyi: and you have problems with the XMLRPC communication?16:20
rvalyibut that would be an eTiny that would be easy to customize, benefitting from all the Rails power16:20
rvalyinot wth XML/RPC that one is easy16:20
rvalyithe problem is: I can't re-implement a full blown ActiveRecord back by XML/RPC that's too much work16:21
rvalyiso what else can I do:16:21
rvalyiI can back the most usefull method lile find(:id) by XML/RPC16:21
rvalyiI've this working already16:22
CIA-53tryton: matb roundup * #673/Stable version 1.0.2: cannot create new database: Applied d920fe52cacb to 1.0.2 and works for me16:22
rvalyiand exposed RESTFully using ActiveResource16:22
udonorvalyi: don't know the concepts of RESTFully using ActiveResource, ActiveRecord?16:23
udonorvalyi: is it ruby or openERP?16:23
rvalyiActiveRecord is the Rails ORM16:23
rvalyiI want to back it by OpenERP16:23
udonoACTION get an idea, slowly16:23
rvalyiREST is the way to expose things on the web, built for simplicity and scalability. Google GData API is restfull for instance16:24
rvalyiOpenERP/Tryton aren't restfull and it suck16:24
rvalyithey use HTTP POST (XML/RPC) for idempotent requests, that suck16:25
rvalyiActiveResource is the Rails framework putting exposing resources RESTfully16:25
rvalyiBasically, ActiveRecord could deal with OpenERP associations (like sale_order.order_lines) easily if I connect it to the dababase directly16:26
rvalyiI can't do only that because that won't enforce the security rules (easy to reimplement though) neither work with computed fields (that's the point)16:27
rvalyiso, an option is to have an hybrid ActiveRecord: half backed by the OpenERP DB directly16:27
rvalyiand half back by XML/RPC for computed fields16:27
rvalyibut I find it very strange, I don't know if that's crazy or not16:28
udonorvalyi: makes no sense for me. Sounds undoable. You have an ORM which is under development and the API of Tryton/OpenERP which is under heavy development. I would not use a rubi ORM to interact with Tryton/OpenERP. Also I would not directly connect to the database layer, it breaks three-tiers. Instead use for simplicity an XMLRPC wrapper.16:28
rvalyiif I only use the XML/RPC wrapper, I can't re-implement the associations, that woul be to much work16:29
rvalyithen I don't knwo if the framework is usefull16:30
udonorvalyi: don't understand.16:30
rvalyiI don't want to re-implement eTiny: too much work too, espcially all the javascript quirks16:30
rvalyiRails is able to deal with model association as, performing SQL joins under the hood16:31
rvalyiI can't benefit from those JOINS and transform them into XML/RPC requests: too hard/too much work16:32
rvalyiunless If I plug Rails directly on the OpenERP database, specifying the foreign keys, then associations would work out of the box16:33
udonorvalyi: All the client server communication is done with XMLRPC, so you can do the same. But if you like to make it as flrxible as the client do, there is no other way then to write (another) client...16:33
udonorvalyi: pluggin Ruby directly to the database is a short solution. I promise you will have a lot of work to maintain it. Even more work then reimplement the client core functions in Ruby.16:35
rvalyiudono: the point is that: either I re-implement a client, inferring the joins from the XML/RPC meta-data, but then that's a full blown client and not a Rails standard data model16:35
rvalyi, either that a Rails std data model but with no support for the JOINS a nd advanced operations16:35
rvalyiudono: my goal wouldn't be to re-implement a client (why?), I just woul like to make it straightforward to write a Rails app, using OpenERP, eventually as the back-office16:36
rvalyisay I implement a killer CMS Front Office in Rails and let the back office backed by OpenERP16:37
rvalyiI've too run, sorry16:37
udonorvalyi: of course, because you want to connect to a modular system where you don't know which modules come and in the case of openERP you even don't know wich modules are already there. So implementing on database level means you need to check every change in framwork and all models, if they anylonger fit to your ORM concept. Implementing on XMLRPC level you just need to check if some general concept changes in one of the client.16:38
-!- bechamel(n=user@ has left #tryton17:26
-!- bechamel(n=user@ has joined #tryton17:27
CIA-53tryton: matb roundup * #675/Exception: ('UserError', 'Invalid XML for View!'): [new] Installing modules with -i all in new database: [Sun Dec 14 16:33:50 2008] INFO:init:module:account:loading fiscalyear.xml [Sun Dec 14 16:3 ...17:47
-!- cristi_an(n=cristi@ has joined #tryton18:18
cristi_anhi to all18:21
cristi_anis somebody active this sunday evening ?18:22
Timitoscrisit_an: hi ;-)18:23
cristi_anhey hey18:24
cristi_ani have been quite busy this week and did not had too much time to digg in more18:25
cristi_anpricelist ?18:28
cristi_anfor tryton...or your prices for your services ?18:28
-!- carlos(n=carlos@ has joined #tryton19:03
cristi_ancompanies....are different entities as partners ?19:25
cristi_ancomanies are not the entities that are the "owner","users" of the application ?19:26
Timitoscristi_an: companies are the companies that are managed with tryton19:26
cristi_anyes...that is what i said in my own words19:27
cristi_anbut i created a company19:27
cristi_anand it appears in my parties list19:27
cristi_anwhich i assume are customers and suppliers19:27
Timitoscrisit_an: yes this is intended as the company can also be a party19:28
cristi_anTimitos: i see19:28
Timitoscristi_an: you can also relate the users of tryton to a party19:28
cristi_ani understand.19:28
udonocedk: having problems with the new view inheritance an on_changes.19:57
udonocedk: generally it is a good think, I find. But I have the problem, that the on_change is searched in the main model which inherits other models.19:58
udonocedk: I have company --> party --> party_type inheritance. Now the company shows all views I defined in party_type, But some widgets have on_change methods defined in party_type. If I change one widget in the company, I get the error: Calling method on_change_type on object is not allowed.20:00
udonocedk: do you know what to do?20:00
udonocedk: another topic is the restrict handling of x-path expression. I don't like to show some widgets on company, so I need x-path expression which can fail without error.20:02
cristi_anAdminstration module is described in a document or so ?20:27
cristi_ani am very courious what can i do with models (not modules)20:28
cristi_anwhat are for example record rules20:28
cristi_anwhat are and how can be used wokrflows20:29
cristi_anetc etc20:29
-!- rvalyi(i=564b0b39@gateway/web/ajax/ has joined #tryton20:50
CIA-53tryton: matb roundup * #657/Additional fields of inherited report also created for parent module: very strange: initially with one new database and the custom module installed it seemed to work (trans_odt_inherit1.png), but I couldn't reproduce ...21:07
CIA-53tryton: matb roundup * #657/Additional fields of inherited report also created for parent module: Forgot summary: So now the items are only shown as belonging to module account_invoice, no more entries for account_invoice_custom.21:08
-!- Cristi_an(n=Cristi@ has joined #tryton21:20
-!- vengfulsquirrel( has joined #tryton21:37
rvalyiguys, for those of you who noticed the recent debate around dates in account move lines in OpenERP, is looks it has been fixed: (see comments)22:30
cedkrvalyi: we had it since very long time, but I don't know how OpenERP will handle the migration22:32
cedkas it can have many dates for one move22:33
rvalyicedk: they didn't put it at the move level22:33
cedkrvalyi: where ?22:34
cedkrvalyi: I can not check as launch seems to be again down22:34
rvalyi2 sec22:34
rvalyicedk: sorry, it's actually at the account_move evel, but not the account_move line level22:36
rvalyiI guess a account_move is like a stock.picking then22:37
rvalyicedk: were you talking about the migration from 4.2 to 5 ?22:37
cedkrvalyi: yes of coursr22:37
rvalyiIMHO, for accounting that would be VERY VERY hard22:37
rvalyiI don't even want to try22:37
rvalyithat's why we put all our new customer to v522:37
cedkrvalyi: if you have two dates on lines from the same move, which one will be migrated22:38
rvalyiwe don't want to migrate them22:38
cedkrvalyi: ok, for news, but think about old users22:39
rvalyicedk: I played with a Rails app connected to the OpenERP server viw XML/RPC, but I'm stucked, interrested?22:39
cedkrvalyi: by the way, I talked about this issue 1 year ago22:40
rvalyicedk: I think old user have to forget about migrating their accounting, I would forget22:40
cedkrvalyi: that is exactly what I named lake of long term vision22:41
rvalyifor sure from v4 to v5 they didn't have that vision22:41
cedkrvalyi: and don't you fear that the migration between 5.0 and 5.1 or 6.0 will not be also possible ?22:41
rvalyiI hope they will do better from now one with larger contracts runnning, otherwise they will have dib troubles22:42
cedkrvalyi: it is not a new project, so if for the version 5.0 they do this why not for futher22:42
rvalyiI hope they are aware they are changing of scale now and they should do things more professionnaly, but I should say I do have concerns22:42
rvalyicedk: but before v5, they were hardly getting enough money (right?) so that was OK: no money, then no constraints. Now there is a lot of money flooding I think, so they will no longer have this excuse22:44
cedkrvalyi: what do you know about the money in Tiny?22:44
rvalyiwell, I'm guesing I should say22:45
rvalyibut since some of the few guys they contracted had both no passion for open source + no talent, I guess they had not enough money to attract them22:45
rvalyinow I think they are booming, so I think they should get some money22:46
cedkrvalyi: don't understand whet you mean22:46
rvalyithat was just about inferring there financial situation after their marketting/team22:47
rvalyiI'm sorry, but when Fabien isn't there, it looks like there is nobody at Tiny.be22:47
bechamelmoney and vision are two different thinks, lot of amateur projects have great visions and the opposite is also true22:47
rvalyiI saw your commits so I'm not talking about you guys22:48
bechamelrvalyi: it's a lack of delegation22:48
rvalyiyeah, but my point was: before having money, I could perfectly excuse them. Now it's different22:48
rvalyiI mean forgive them for not having the long term vision22:49
rvalyiof course, I can't understand they still don't cross ref their fucking bugs/commits and they don't write docstrings22:49
yangoonrvalyi: customers that cannot upgrade have to forgive...22:49
-!- vengfulsquirrel( has left #tryton22:49
bechamelespecialy when your are the one who pays ;)22:49
rvalyibechamel: they were not enough paying compared to what ERP really cost. Or not paying enough, as you want.22:50
cedkrvalyi: I don't think so22:50
rvalyiSAP and others can only run because A LOT of money is flooding in22:50
rvalyithey just had what theyr should for their money I think22:51
cedkrvalyi: and if you look the answer from Fabien about the lake of long term vision, he says that they have it since the begining22:51
rvalyicedk: sure; almost everybody think this is some geek attitude that needs more maturity22:52
cedkrvalyi: so it seems that the migration from 4.2 to 5.0 is in their long term vision22:52
rvalyibut, I'm among the few ones who dare believed they could improve with the extra monay they are making now22:52
rvalyiI think migrating form 4.2 is doable on a limited perimeter (without accounting)22:53
rvalyibut also I doubt accounting was really OK before in v422:53
cedkrvalyi: except that accounting is surely the most important stuff for a company22:53
rvalyiat least for French standard it wasn't quite that22:53
bechameli don't agree, look at postgresql, it's a software that is IMHO more important part of tryton/openerp, it's maybe more valuable thant the python layer above it. but it's completely free, there is a good vision, it's very stable and each release is getting better22:53
rvalyiI think it's far more easier to build a SGBD than an ERP unfortunately22:54
cedkrvalyi: I don't think so, but for devs it is more funny22:54
cedkrvalyi: will you say the same for a kernel, or a graphical library ?22:55
rvalyiit has its hard parts, But I think overall it's a lot simpler. Less diferent things to master. Plus it will have a broader tech community, so this helps to. Unfortunally, most if the guys understanding ERP functionnal don't master computer science22:55
bechamelerp world is not very  sexy :)22:55
rvalyicedk: I actually think a full blown ERP is not that far from a kernel indeed in term of hard to get done right22:56
cedkrvalyi: so it is not easier but it is more sexy for devs than ERP stuff22:56
cedkrvalyi: I think you under valuate a kernel dev22:56
rvalyiPLUS: the accounting community is divided geographically which does not happen in other open source projects like kernel or SGBD22:57
cedkrvalyi: by the way, I think there is more ERP software than kernel in the world22:57
rvalyicedk for sure a kernel is harder, but I mean an ERP is closer to a kernel than a CMS22:57
cedkrvalyi: CMS can mean many things22:58
rvalyicedk: interresting: but how many full blown open source ERP that are working for real?22:58
rvalyiI really think OpenERP,Tryton are the only working ones22:58
cedkrvalyi: and about the geographical division, it is very closed to different hardware22:58
rvalyiplus Compiere if you like but it's hardly open source22:59
cedkrvalyi: I talked about every ERP also the closed22:59
rvalyiwell, closed can be anything. It's just a lot of money involved, so for sure they can afford it22:59
rvalyiand most of the ERP's started more than 15 years ago..23:00
rvalyiif not in the late 70's like SAP R/323:00
cedkrvalyi: how many kernel do you know ?23:00
cedkrvalyi: and compare it with how many ERP do you know ?23:01
bechamelthere is alos a lot of specialized soft, who can be seen like partial erp23:01
cedkrvalyi: and the same with databases23:01
cedkand ERP can means a lot of things23:01
bechamel@all, about geekness, it's an issue that comes often to my mind, what should be done to remove/reduce the geeky aspect/feeling of openerp/tryton ?23:02
rvalyiI mean, to manage to build a full blown generic ERP, you have no choice be also master a modular plateform, like Eclispe. Else it's not modular, it's monolithic and hererogene like SAP, but that second option means a LOT of money to maintain it23:03
-!- mmarshall_( has joined #tryton23:03
rvalyibechamel: a few ideas, may I tell:23:04
rvalyi* docstring + document stuff as it comes23:04
rvalyi* continuous integration server + A LOT of functional tests, not the simple tests they have + public access to test result as new commits are made23:05
rvalyi* stop re-inventing the wheel, plug on a real web server, use solid library. Use a standard ORM...23:05
rvalyistop tag commits: as improvement and bugfix: explain what you do (they still don't)23:07
cedkrvalyi: that is for OpenERP23:07
rvalyipossibly use statically typed low level layers so stability is enforced by a compiler (for lowest layers, not the functionnal layer which is right in a dynamic language)23:08
bechamelrvalyi: what do you call continuous integration server ?23:08
rvalyicedk: sure, you are doing better here, no question23:08
rvalyibechamel: a server running lots of tests and displaying the results23:08
rvalyilike Bamboo fro instance23:09
rvalyithey are a ton of others, can't remember23:09
rvalyialso : do and publish load tests23:09
bechameli agree with most of your items, but there are not easy to solve23:09
bechamelmost :)23:10
cedkbechamel: no we already most of it23:10
rvalyigood for you23:10
bechameltests are boring to write and there are useful only if they provide a complete coverage (this means a lot of code)23:11
cedkbut I don't agree with typing23:11
rvalyiI think the issue with Tryton are others23:11
bechameluse a proper orm: dificult because the current pseudo orm do a lot of thinks23:11
rvalyifunctionnal tests are not meant to cover all the code as it's imposible, but just ensure stupid regressions does not occur23:11
rvalyias it occurs everuy week with OpenERP23:12
rvalyibechamel: I don't think your ORM do more than ActiveRecord (Rails), do you?23:12
cedkrvalyi: we started to write unittest, but it is a good idea to make it running weekly on a server with public output23:12
rvalyiwhy not running it continuously23:13
bechamelrvalyi: the modularity also tends to complexify the situation, test should be done with a lot of  different combinations of (non-)installed modules23:13
cedkrvalyi: doesn't need more23:13
rvalyipeople having a web interface can use Selenium for this, it's great23:13
rvalyiguys, anyone, interested in discussing my Rails connector proto?23:13
cedkrvalyi: I don't know rails23:14
bechamelrvalyi: sorry if it sounds harsh, but imho rails connector is a bit geeky :)23:14
rvalyiusre it is23:14
rvalyierr, sure it is23:14
rvalyiI've no problem with being a geek myself, but I should say it's a bit more tough to sell that to companies23:15
rvalyimy goal was to have a Rails plugin that make your OpenERP/tryton data model available in a standard Rails app (like a CMS, an ecommerce). So I was backing the Rails ORM by XML:RPC requests to OpenERP/Tryton23:16
rvalyiBUT: if I do only XML/RPC, then I can't easy support associations/joins, so I can support only a very thin subset of the Rails ORM23:17
cedkrvalyi: I don't understand, ORM is to connect to a database and not to objects23:17
rvalyiI can almsot expose the OpenERP data model RESTfully, but I can't convert it on the fly to json or XML as a standard Rails model23:18
rvalyicedk: I'm faking the ORM interface, but it's baked by XML/RPC to OpenERP server23:18
cedkrvalyi: but models are not just data, there is workflow, function, rules and so on23:18
rvalyisure, I don't really need those23:18
rvalyimy goal is not to build yet an other client23:19
cedkrvalyi: so your ORM has only minimal stuffs like read, search, create, delete ...23:19
rvalyibut to help building a custom web app talking to OpenERP in the most transparent manner possible23:19
rvalyicedk: exaclty23:19
rvalyitheir is a second option still:23:19
rvalyihave an hybrid system23:19
rvalyiwhere my ORM is both:23:20
bechamelrvalyi: what's your goal, another etiny (rtiny)? or someting more periferal (like a webshop) ?23:20
rvalyi1) backed by XML/RPC, this is especially sueful to load computed fields, enfoce access rules and all23:20
rvalyibechamel: no goal yet, just for fun for now23:20
rvalyi(ecommerce or anything would then be possible)23:20
rvalyi2) other part of the ORM:23:21
rvalyiit would aslo plug directly to the OpenERP database, so:23:21
cedkrvalyi: I don't understand to goals, if it is to write a webapp in ruby, just write your application and make some xmlrpc calls23:21
bechamelrvalyi: i think something like an active gateway between rails and openrp is doable, another etiny must be very difficult23:21
rvalyiI would have associations working out of the box23:21
rvalyi+ to_xml and to_json would also work23:21
rvalyibechamel: exacly I don't want to build yet an other eTiny because that's too much work, especially the Javascript quircks23:22
rvalyicedk: I would like the Rails to behave like if the OpenERP data model was part of it seamlessly23:22
-!- yangoon1( has joined #tryton23:22
bechamelrvalyi: doesn't rails comes with easy javascript features ?23:23
rvalyilike doing Parner.find(1).sale_orders would fire up the right XML RPC requests and you could just display the result in your templating system for instance23:23
rvalyibechamel: sure, but I mean re-doing eTiny in rails would take me 3 months, that's too much for a geel project23:24
rvalyi,err geek spare time project23:24
cedkrvalyi: ok, like making a library that bind to the ORM23:24
rvalyicedk: exaclty23:24
rvalyiso my main questin is;23:24
cedkrvalyi: that must be not too difficult, depending on how many methods there is in ruby23:24
cedkrvalyi: and the problem will be that xmlrpc is not very efficient23:25
rvalyiwhat do you think about such an hybrid model: both connected to the database, but also retrieving./writing fields using XML./RPC, and performing the JOINS via native Rails SQL abilities23:25
rvalyicedk: (that's an other issue for sure)23:25
cedkrvalyi: you must do everythings throug xmlrpc23:26
rvalyihow do you think the database will behave if it's requested at the very same time both by a Rails app and OpenERP server (to complete the requests for the python computed fields)?23:26
rvalyicedk: then I can't easily support joins and all, because Rails is simply doing too much under the cover, I think I can't afford writting a wrapper for all the stuff23:27
-!- vengfulsquirrel( has joined #tryton23:28
rvalyifor the moment I have an OpenERP resource (model), or even collection, exposed restfully mosty working23:28
cedkrvalyi: don't know what is joins and it is not a problem if you don't suppoert every method as soon as it is documented :-)23:28
rvalyibut I was curious if more was not easy to do23:28
rvalyicedk: join: like whe n you do sale_order.order_lines this is a join between two models/tables23:29
cedkrvalyi: so simply ask for order_lines to sale_order model23:29
rvalyiRails can do this out of the box if you plug it to the database, but if not, then Rails will try to fire SQL JOIN request and it will be hard for me to intercept that and fire XML/RPC instead23:30
rvalyicedk: sure, I've this already but I would like to know what I could do to offer more, just like if you were working with a Rails model23:30
cedkrvalyi: for me you must provide an alternative library then the rails ORM that has the same methods23:30
rvalyi(or an OpenERP one)23:31
rvalyicedk: That's what I started23:31
cedkrvalyi: you must do somthing like the BrowseRecord23:31
rvalyibut the point now is: if I don't plug Rails to the DB, then no JOIn natively suppored (too hard), if I do the contrary (hybrid sytem), what are the implications of such a system23:32
rvalyiIf following option 1), I could  have somthing like:
cedkrvalyi: that seems to be good23:34
rvalyiwell, my question is isn't there anyway to get more easily?23:35
rvalyiI don't think I'll do all myself23:35
rvalyibut I'll post my ideas/code snippets on the internet and courageous people with more time could improve it as they whish23:35
rvalyiI just would like to build a proff of concept actually23:36
cedkrvalyi: I don't know enough about Rails ORM23:36
rvalyicedk: no problem23:36
rvalyisorry, dinner time for me23:36
rvalyiwil be bac in an hour may be23:37
-!- vengfulsquirrel( has joined #tryton23:57

Generated by 2.11.0 by Marius Gedminas - find it at!