openerp-community team mailing list archive

[Niels Huylebroeck <nh@xxxxxxxxxx>]

> The idea would be that this is a TransientModel thus model stability should
>> matter very little correct ?
>>
>
> No, TransientModels are database-backed (for statelessness reasons) so it
> does matter as much as for regular Models.
>
>
Thanks for confirming that.


>      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.
>>
>
> I don't see why auto-detecting modules that belong to a special predefined
> category would represent an issue, either for user-friendliness or for
> conveying the module's meaning (implementation detail?). Actually that's
> what the accounting system does to detect the available chart of accounts:
> any module that belongs to the "Localization/Account Charts" category will
> be dynamically added to the selection box.
> Anyway, that was just a random idea.. ;-)
>

My response on naming conventions was mainly on the module name itself,
this is something very subjective and will rarely give any substantial
value to an end user looking for a solution to his problem.
The category approach is indeed a fair approach, the reason I would like to
have one major configuration module per category
(account/stock/project/sale/purchase/...) is to embed more detailed
information about showing the user what options he can toggle (while not
caring about the name). The module would itself not be any different from
the official approach of a configuration screen that installs modules in
the background.

The only difference I want to stress is that this module should:
* only allow installing tweaks for which the dependencies have already been
met
* provide a fairly detailed and visual (screenshot/video/chart) to show the
difference compared to standard behaviour.