Sales Order Lines, XML-RPC Webservice

[Whisnu]

I created one Sales Order using XML-RPC and then created Sales Order Lines use the same way. After the process of Confirm Order till delivering the products, I cannot add more product from Web CLient or GTK Client to my Sales Order Lines (and this is good) but I still can add more product using XML-RPC

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Yeah, lot's of data integrity is controlled via the interface rather than the model level unfortunately. This is rooted in the heart of OpenERP design, I believe it could be improved only in the long run unfortunately.

[xrg (xrg)]

On Monday 31 January 2011, you wrote:
> Yeah, lot's of data integrity is controlled via the interface rather
> than the model level unfortunately. This is rooted in the heart of
> OpenERP design, I believe it could be improved only in the long run
> unfortunately.

Exactly . There are some design decisions that date back to pre 5.0.0 days and
prevent us from doing "what is expected" with the framework. It is not easy to
change everything in one go; we sometimes prefer to do 'mild' corrections that
will counter-act that design.

[Marco Dieckhoff (dieck)]

Without knowing the client code, just food for thought.

I suspect it could be possible (but most likely not that simple) to take the client, keep the "framework relevant part", and switch the graphical frontend to an xml rpc server, thus creating an xml rpc "proxy" observing consistent rules and procedures.

[xrg (xrg)]

On Monday 31 January 2011, you wrote:
> Without knowing the client code, just food for thought.
>
> I suspect it could be possible (but most likely not that simple) to take
> the client, keep the "framework relevant part", and switch the graphical
> frontend to an xml rpc server, thus creating an xml rpc "proxy"
> observing consistent rules and procedures.

I'm afraid what you say is far from the current situation.

And the discussion is not at all about XML-RPC (bad title), but about the fact
that we have RPC (as in remote _procedure_ calls) rather than remote _session_
calls.
Think of HTTP/1.1 and the merits that stateless connections have brought to
it. At the same time, those stateless connections meant that all form data
needed to be carried back and fourth from the client. And then, various
workarounds where invented, such as the cookies, sessions, even total
circumventions like AJAX-backed full javascript ORMs in the http client..

Here, we're talking about solving some of the deficiencies of the current
design, with the least possible intervention to the rest of the framework[1].
It will certainly need good thinking..

[1] I personally like the fact that our RPC is somehow free and we can, for
example, restart the server without destroying a client's session.