← Back to team overview

openerp-community team mailing list archive

Re: Usability features branches

 

> So when it comes to MPs, it will really depend on the kind of "fix". Some
> improvements would be acceptable in trunk (with an appropriate priority),
> and you can assess that yourself in most cases: is it completely generic,
> is it likely to puzzle first-time users, etc.
>

Can't help but beating this dead horse one more time: more and faster
feedback from OpenERP on merge proposals please, communication is key here
to get an understanding of how OpenERP wants to progress further. Right now
it still feels like saying prayers at night and hoping someone hears it and
maybe someday might respond.

Even small communication stating conflicts with openerp ideology is fine
for me, anything but ignorace!

For the rest, it might be better to put them in extra modules and offer a
> configuration interface similar to v7's "Settings" checkboxes, possibly via
> an index module, as Niels suggests. But you should watch out for
> updatability - a stable series ideally requires modules to be frozen at the
> data model level, and this won't be the case if you need to add an extra
> column in the settings model whenever you add a "tweak" module.
>

The idea would be that this is a TransientModel thus model stability should
matter very little correct ?


> Perhaps you could do this via a module naming convention or module
> category naming convention? Let's say your "index module" adds an extra
> Settings page: it could dynamically generate checkboxes to install any
> local module that matches the given prefix or belongs to the special
> category. The module summary and [sub]category could be sufficient to
> present a meaningful config page without actually needing to install the
> modules, and without changing the actual data model when a new module is
> available.
> It sounds like a lot of overhead to manage a few tweaks, though.


Naming conventions are a pain, subjective and do not reflect the idea
behind a module very efficiently. Nor do users know what to look for if
they are not familiar with OpenERP terminology.

The idea is to bundle all the overhead into a few major modules which
hopefully we can get accepted in the core (although to be honest that is
not the primary/secondary goal atm).

Follow ups

References