> I agree that speed entry is a major problem in the current web client v5. > Having editable grids (see my previous posts) and avoiding superfluous clicks > when creating new one2many items are the best way to fix this, in my opinion. > In the mean time, users who want faster entry are stuck with the gtk client > (which only works efficiently on LAN).
I agree with all those points and consider it a hot issue, way hotter than relooking indeed... Moreover, here are some other extra ways to require less user clicks: - make dynamic domain work on selection widget: in a lot of place where many2one widget popups are used, the user will never want to create a new resource and there are only a few choices (the product configurator is a good example of it). So it's important to be able to swicth the many2one widget to a dropdown (selection), avoiding one click and one slow popup with a server round trip. https://blueprints.launchpad.net/openobject-server/+spec/dynamic-domain-on-selection-widget - make it easier to create a new resource in just one click on many2one widgets. For instance for creating a new partner in a quotation form, since the edit partner button is disabled when no partner is selected why the hell can't we have instead a new button to create a new one in one click instead of 2? I believe it was like that in early 4.x Tiny versions, why did that change? - currently forms can pass parent form params to on_change methods that can themselves alter the form content, fine. However, it makes no sense the on_change can not also change parent forms. Again the product configurator is a great illustration of that limitation: once you selected all dimensions values, the matching product variant can't be selected automatically because you were triggering on_change in an inner form. https://blueprints.launchpad.net/openobject-server/+spec/form-parent-field-update-on-change - new osv_memory wizard lack a few miles to replace old non OOOP wizard completely (can't be on the right side or apply to a group of record). This is sad because new osv_memory wizards support on_change which can save some clicks to the user. The sad part is that the little Tryton fork already fixed most of these things and this hasn't been spotted by Tiny as something important (no blueprint feedback, no feedback yet on expert teams lists). Hope Tiny considers that important. Let fix that first instead of making tons of new modules with on a limited UI. Once we have a solid platform, module will come on a stronger basis with a more sexy UI. Also please don't let tons of new modules develop on sand one more year before fixing those things. We all know that once bad things are done it costs more to remove/change them than re-do them properly from scratch. Because osv_memory are limited or because of the on_change limitations, lot's of crappy code will be made in the module to work around the limitations: old wizards styles will be copied over and over in non compatible manner... Then it might stay here for ever because customer X is in prod with it. So in order avoiding making X unhappy with his bad yet working code, it costs the whole community/future market, this is not how open source is supposed to advance... So, aside form short term marketing strategy, I see no point in letting that happen. Basically, I'm not saying Tiny should invest more by no mean, I know they are doing a lot already. I just call for considering that sort of things a priority and at least let the community merges enter before 5.2 regarding those points. ------------------------ Raphaël Valyi CEO and OpenERP consultant at http://www.akretion.com -------------------- m2f -------------------- -- http://www.openobject.com/forum/viewtopic.php?p=49512#49512 -------------------- m2f --------------------
_______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman2/listinfo/tinyerp-users
