openerp-expert-framework team mailing list archive

[Olivier Dony <odo@xxxxxxxxxxx>]

Le 14/07/10 21:53, Raphaël Valyi a écrit :
> OK, so here are for us simple things at the framework level (so should
> hurry up before the freeze) we already mentioned but that are still to
> be done to improve usability:

Thanks for this interesting list :-)


> 1 ) one2many widget management in web client like the GTK client without
> the need to create resources one by ones.

o2m widgets will work like this in v6 indeed


> 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)


> 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)


> 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.



> 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).


> 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.


> 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.


> 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.

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.


> 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.


> 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)