> On 28 Feb 2019, at 01:06, Matus Honek wrote:
>
> On Wed, Feb 27, 2019 at 9:10 AM Ludwig Krispenz wrote:
>>
>>
>> On 02/26/2019 04:42 PM, Matus Honek wrote:
>>> This kinda leads me to thinking we should implement ACIs management
>>> within the DSLdapObjects like this (probably specific to
On Wed, Feb 27, 2019 at 9:10 AM Ludwig Krispenz wrote:
>
>
> On 02/26/2019 04:42 PM, Matus Honek wrote:
> > This kinda leads me to thinking we should implement ACIs management
> > within the DSLdapObjects like this (probably specific to a particular
> > subclass, to a degree). One that would take
On 02/26/2019 04:42 PM, Matus Honek wrote:
This kinda leads me to thinking we should implement ACIs management
within the DSLdapObjects like this (probably specific to a particular
subclass, to a degree). One that would take care of this added
requirement for objectclass ACIs because of hidden
There is already features in lib389 for managing aci, but due to the design of
aci in DS they are *super hard* to represent correctly in DSLdapObjects. I
think the existing lib389 aci code could be adapted to extend dsldapobject to
have some aci tranform capabilities, but they wouldn’t be
@Matus Honek
Yes, I agree.
Perhaps we should open one ticket in pagur to track this issue ?
Regards
Anuj Borah
On Tue, Feb 26, 2019 at 9:12 PM Matus Honek wrote:
> This kinda leads me to thinking we should implement ACIs management
> within the DSLdapObjects like this (probably specific
This kinda leads me to thinking we should implement ACIs management
within the DSLdapObjects like this (probably specific to a particular
subclass, to a degree). One that would take care of this added
requirement for objectclass ACIs because of hidden .filter's behavour.
Because that is currently
> On 26 Feb 2019, at 12:58, Anuj Borah wrote:
>
> @William Brown
>
> ACI syntax in test is correct, it meant to give access to (mail = * ) only
> not any thing else . In the same case as mansion bellow:
Ummm, that’s not what I’m saying? I’m saying that you may *only* be giving
access to
