[PATCH 1 of 1 eac V2] [schema] Backport security settings from the saem_ref cube

Denis Laxalde denis.laxalde at logilab.fr
Wed Mar 8 13:56:58 CET 2017


Sylvain Thénault a écrit :
>
>
> Le 08/03/2017 à 12:15, Denis Laxalde a écrit :
>> Sylvain Thenault a écrit :
>>> # HG changeset patch
>>> # User Sylvain Thénault <sylvain.thenault at logilab.fr>
>>> # Date 1488958771 -3600
>>> #      Wed Mar 08 08:39:31 2017 +0100
>>> # Node ID d313d8c5382726a38a88f9c83b659d41a13db449
>>> # Parent  47724158121da77c11fa61c543d855a7a4842fc6
>>> [schema] Backport security settings from the saem_ref cube
>>>
>>> introducing a dependency to the compound cube.
>>>
>>> Benefit of doing so is that client cube only have to setup desired
>>> permission on
>>> the container (AuthorityRecord), and all the subtree will follow
>>> those, which
>>> sounds a good default behaviour.
>>
>> But client cube would get cubicweb-compound as a dependency, which is
>> arguably a downside. If there's no compelling reason for doing this,
>> I'll vote -1.
>>
> Having a complex tree such EAC tree coming with security preconfigured
> is compellling enough, not ? Otherwise we ends up duplicating code which
> is at best error prone. Adding a dependency on compound is cheap.
>

If there's code duplication involved, that's a good reason. Where is
this happening?
The reason why I'm reluctant is that, quite often, security is a matter
of the final application.



More information about the saem-devel mailing list