[PATCH 1 of 1 eac V2] [schema] Backport security settings from the saem_ref cube
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
The reason why I'm reluctant is that, quite often, security is a matter
of the final application.
More information about the saem-devel