openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Hello Olivier and all,


> o2m widgets will work like this in v6 indeed


Great news, so everybody agree we change the status of this bug
https://bugs.launchpad.net/openobject-client/+bug/489308 for the v6 version?



>
>  2) symmetric of forms passing parent form fields, but for changing them
>> this time:
>>
>> https://blueprints.launchpad.net/openobject-server/+spec/form-parent-field-update-on-change
>>
>
> It seems to me you'd just be bloating the system.
> For your product configurator, what about having an on_change on the o2m
> lines that would directly select the product variant if there's only one
> match? (not sure if I understood you example correctly though)


Nope Olivier you can't do that because the product_id is not carried by the
configuration dimension lines but by the parent form. I show here an
overview of the architecture for a given product_template:


   - product_template_id (I assumed on is selected)
   - product_product_id (search is restricted to matching dimensions, once
   all dimensions are set, only one variant matches)
   - one2many: dimension_configurations:
      - Color: Red | Blue | Green
      - Size: Large | Small

So as you see, currently, when you set the last dimension configuration
line, you would like to auto-select the only matching variant.
But you can't do that because on_change inside the one2many widget can't
alter a parent field...
I can see plenty of other use cases where both module developers and users
will get stuck with that limitation.

Please notice that it should be a fairly simple client fix to have it:
if the client receive something like parent.product_id = x, then it set x of
the product_id field of parent widget.
Pretty simple and damn useful, consistent with the read mode.
What do you think?



>  3) option on many2one widget to allow one-click creation without the need
>> to click through the search popup, could be really more user-friendly.
>> I know this was the default behavior in TinyERP 4.X and has been removed
>> to avoid creation of records by mistake.
>> But in v6, that would be cool to have an option attribute to enable that
>> behavior back in some specific forms we want.
>>
>
> Hmm, what about the F1 keyboard shortcut that already exists, instead of
> adding yet another icon in this widget? (F1 works in web and gtk on any m2o
> field, even in editable lists)


Yup, was unaware of those F1, F2 and F3 shortcuts, they are damn useful
indeed! So this one is over. Thanks a ton!

>
>  4) currently in many2one widgets, if only one record exist, then the
>> search button will auto-select it.
>> So you'll have no chance to hit the new button inside the search popup
>> of the many2one, so you can't create a new item here just because there
>> is one and only one -> it sucks!
>>
>
> How about the F1 keyboard shortcut? ;-) Ok this one is more debatable, but
> I would tend to keep it like this.


 Yep, F1 is our life saver today.

>
>  5) I believe one2many and many2many widget still do not trigger
>> on_change events one removing an item. This would be required in some
>> advanced user interfaces to behave properly:
>> https://bugs.launchpad.net/openobject-client-web/+bug/341622
>>
>
> Good point, will be fixed in v6 (and v5 as well I guess).


Good news.

>
>  6) Confirmation dialog pattern: currently, you don't have in OpenERP the
>> option to click to do an action, then the server answers you blabla are
>> you
>> sure? YES | NO
>>
>
> How about the "confirm" attribute of <button> elements, which is in the
> technical memento BTW.


Hum, not sure it's generic enough cause it's pure client side (I'm also sure
few here knew that attribute).
For instance, I would like something when user create a new partner:
"warning a partner exist with a similar name xxx, are you sur you want to
proceed?"
In this case I need to crawl the database (server-side) to know if a partner
has a similar name.
In that specific case, I could do it in an on_change that's right. I'm
sorry, I don't have a proper example in mind,
but I'm pretty sure we can find some (specially if the test to perform is
complex and involves lot's of fields,
like an accounting process, so we don't want to do it in an on_change).

About the memento, would be cool to put a link here too BTW
http://doc.openerp.com/

>
>  7) I believe it's still not possible in a many2one view, to select the
>> view that would popup in the search list view or from record
>> creation/visualization view.
>> Currently we should code for this and override fields_view get and use
>> the context, but I think it would be better to support this natively
>> and declaratively using an attribute parameter.
>> (we do that hack in the fleet_maintenance module for instance).
>>
>
> Hmm, ugly hack indeed. How about doing it the other way around and making
> this view the highest priority form view (thus the one used in the m2o), and
> then specifying another form view explicitly in the action that opens your
> regular list/form views.


Olivier, this is yet an other hack. Take the RMA screen: we here need to
customize the picking form views. The picking views are used so much in
OpenERP that I'm pretty sure that if I put my RMA specific views with a high
priority,
then OpenERP will picking up that specific view in lots of modules where it
was not supposed to.
And again, this is just like the selection and on_change issue: it work only
fof one module that need it. As soon as two modules try to rely upon this
for the same field/view, then are likely to be incompatible...
Not to bad for integrators that can always build modules over modules
(though I'm not sure our customer see the added value here) but certainly
very bad for a SaaS prospective were user expect module to just work
together no matter the combo...


8) In one2many and many2many widgets, a cool thing is that we can
>> control how the list will appear by specifying a specific list view.
>> A cool one2many widget option would be a list representation of it with
>> only the selected record. That would allow to control the way the
>> many2one record is displayed.
>>
>
> I don't think I see enough valid use cases for this feature.
> Overriding the name_get() of the relationship object seems a clean way to
> do this for me (you could probably make it dynamic using the context if you
> wanted)
> And having a custom function field in the parent object as you mentioned
> also seems ok to me for special cases.
>

Well, it's up to you of course, indeed, overidding name_get could do the
job, though not as beautiful as the dedicated widget that would appear if
doing the way I proposed.


>
> Another nice alternative I see would be to reintroduce a "one2one" widget
> that embeds the form view of the target object in the source object. This
> way you could design yourself the appearance of the object.
> But that won't be in v6 for sure.


May be. In any case, raw roadmap for next version would be welcome too.

>
>
>  9) we still lack straightforward navigation from sale order to related
>> pickings and invoices (Please read that thread:
>>
>
> In v5 you can already click on the picking in the history tab and even
> click to open its form view, and we'll add the same for the invoice as well.
> I think that's sufficient, plus having context links on the right side if
> you want to go to the full list view.


Yes, would be nice to have some consistency between those embedded relations
and the right side links. Would be more straightforward for the user to
learn.

>
>  10) Finally I think it's important to make sure the OpenERP clients can
>> easily display third party DHTML widgets in place of OpenERP widgets
>> (like iGoogle or Netvibes portals).
>> I think we could reuse the url widget for that. Indeed, currently it
>> would be hard to have a clean cross platform implementation of a webkit
>> DHTML widget on thye GTK client (and in any case it's not done), that
>> means that
>> probably only the web client would support it.
>>
>
> In v6 we're trying to implement 2 things that should help for this,
> including for your more generic concerns:
>
> - allowing HTML architecture for a view (presumably in GTK that would mean
> we indeed need a cross-platform DHTML widget, or we don't display them)
>
> - introducing web addons, which can implement custom controllers or custom
> widgets for the web client (presumably these wouldn't be easily available on
> the GTK though)
>

I know about web addons, but please, for that to be straightforward for the
non expert user, please consider:
https://bugs.launchpad.net/openobject-server/+bug/595783
Also, I'm not sure you will be able to implement cross platform DHTML inside
the GTK client, I mean if you can that's cool.
But if you cannot afford to develop it, then please think about the
iframe/URL degradability I mention.
In a word: yes the best is the best, but sometimes the best in the enemy of
the good. And biodegradability is better than nothing and cost very little.

Thanks for you hints and comments, we are already testing v6 heavily here
and like all the good stuff that has been kicked in.


Raphaël Valyi
Founder and ERP Consultant
+55 21 3010 9965
http://www.akretion.com

<http://www.akretion.com.br/>