openerp-community team mailing list archive

[Olivier Dony <odo@xxxxxxxxxxx>]

On 09/16/2013 09:26 AM, "Lionel Sausin, de la part de l'équipe informatique
Numérigraphe" wrote:
> Hi, Personnally, I would most appreciate if you made merge proposals to the
> trunk when applicable.
>
> I known OpenERP SA is not reactive to this type of MP's (I have made quite a
>  few myself that not been reviewed for months/years). Even though, I remain
>  convinced that most of this this belongs to the core. Maybe if the
> community reviewer made a first review it would help the R&D team process
> the MP's faster ?

One thing that's easily overlooked is that OpenERP is a very complex piece of 
software, and the R&D team spent *a lot* of efforts during the last few years 
in order to simplify it for new users.
That is the single most important criterion when it comes to usability, which 
is a highly subjective topic in the first place. So if the trade-off is to 
require an extra tweak for advanced cases vs having first-time users be puzzled 
over a field's meaning, the balance will be in favor of the former, in most 
cases. Because you won't ever get to the advanced case if the user can't finish 
the first workflow. And generic trumps specific, of course.

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.

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.

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.