credativ team mailing list archive

[Raphaël Valyi - http://www.akretion.com <rvalyi@xxxxxxxxx>]

On Wed, Dec 14, 2011 at 10:25 AM, Olivier Dony (OpenERP) <odo@xxxxxxxxxxx>wrote:

> On 12/14/2011 01:13 PM, Nicolas Bessi - Camptocamp wrote:
> > Hello,
> >
> > I agree with you Olivier, but I do not find the current
> > implementation of hiding module is that friendly for developers.
>
> I agree that the implementation is incorrect at the moment, and that is
> why I was not too specific yet about how to use these features ;-)
> We're going to clean this up before RC1.
>

You know, if you did not called that previous pre-alpha in October a "RC1",
I'm sure we would have be been really less frightened a made less noise
about merges not being processed.

In any case, it seems a good readability improvement to distinguish modules
that have some concrete utility from purely abstract modules. If this is
what you are meaning with the new "Apps" flag, I think this will help quite
a lot.

Now, there are still important issues with module proliferation. Yesterday
I was discussing with Alexis to help porting the fleet maintenance module
to 6.1. Concrete issue we had: on the invoice we need a foreign key link
back to the main picking. So we added that many2one field in the module and
preyed methods would be modular enough so we could propagate the filed at
invoice creation also without killing performance with stored
fields re-computation.
Now imagine 2 modules need that kind of like (like report_intrastat may
need it too), then what do we do: each of those 2 modules add its own field
pointing to the same resource redundantly? Should they use the same key and
then assign it twice? Should we create yet a new base_foo abstract module
just to add that key. Probably it will be ignored by the community and many
such modules would exist... I mean those are the concrete issues we face
daily and for which no solution exists. It produce a module proliferation
hell that is totally opposed to out of the box usability which however
would be the only scalable model. So not sure Sebastien proposal was the
solution, but we certainly should adopt policies or features to deal with
those issues.
Experienced partners can always tune a particular installation to make it
work. But when I see your account managers that seem to be starving of new
implementations wondering why there are no more partners doing more
implementations at new frontiers, those issues that kill out of the box
compatibility certainly have an impact here.



>
> > At that time you have added this domain on modules view action:
> > <field name="domain">['!',
> > ('category_id.parent_id','child_of','Hidden')]</field>
> >
> > Instead of using a default filter on search view that is only
> > accessible to Technical feature group members.
>
> Yes I think that was a temporary attempt to quickly test out our new
> module dashboard view (kanban) without the mess of technical modules,
> but it needs improvements.
> Your suggestion sounds good, we'll apply it while we cleanup these 2
> areas: technical modules and auto-installing modules (I think the 2
> concepts should be separated too)
>
> Thanks for the feedback!
>
> --
>
> https://code.launchpad.net/~sebastien.beau/openobject-server/autoload/+merge/84512
> Your team OpenERP Framework Experts is requested to review the proposed
> merge of lp:~sebastien.beau/openobject-server/autoload into
> lp:openobject-server.
>

-- 
https://code.launchpad.net/~sebastien.beau/openobject-server/autoload/+merge/84512
Your team OpenERP Framework Experts is requested to review the proposed merge of lp:~sebastien.beau/openobject-server/autoload into lp:openobject-server.