Re: [Unity-idm-discuss] Attribute Statements

[Krzysztof B. <kb...@un...>]

Hi Björn,

W dniu 13.09.2016 o 11:31, Björn Hagemeier pisze:
>> If yes - what misbehavior do you get?
> The attribute in question is set to the same value for ALL entities in
> the parent group.
>>
>> And please provide details of the attribute statement that you use to
>> copy the attribute in question.
> In order to copy the attribute from sub-group servers
>
> Extra group with attributes: /unicorex/servers
> Condition: eattrs contains 'urn:unicore:attrType:role'
> Dynamic attribute name: urn:unicore:attrType:role
> Dynamic attribute values expression: eattrs['urn:unicore:attrType:role']
> Dynamic attribute visibility: unlimited
> Conflict resolution: skip
>
> And for sub-group users:
>
> Extra group with attributes: /unicorex/users
> Condition: eattrs contains 'urn:unicore:attrType:role'
> Dynamic attribute name: urn:unicore:attrType:role
> Dynamic attribute values expression: eattrs['urn:unicore:attrType:role']
> Dynamic attribute visibility: unlimited
> Conflict resolution: skip
>
> The list entry (toString()-rendering?) of this statement not mention the
> extra group, such that they look alike at first sight. But this is
> probably just a UI issue.

It is intended: the extra group is skipped so the statement's string 
representation is more compact.


> With conflict resolution 'skip', the first statement in the list wins,
> with conflict resolution 'overwrite previous', then last one wins. This
> is expected behaviour, but values are applied to all entities in the
> parent group. I've attached what I think is a minimal example of this
> problem. It's a database dump from a fresh Unity installation with all
> example data removed. Maybe it helps in debugging the problem.

The dump was not consistent with the above description and the 
description was not enough to reproduce. Fortunately putting them 
together helped.

So there is a bug. It can be triggered only if when creating a statement 
in a group, in which you relay on attributes assigned by another 
statement in extra group. This is what you used (not written above but 
this is the only statement that was present in the dump). More 
precisely: Unity, when evaluating statement of a subgroup doesn't ensure 
properly that the entity for which attributes are collected, is actually 
the member of this subgroup. It simply assumes that the entity is the 
member. This is always correct for parent-extra-groups, but naturally 
not for sub-extra-groups.

I'll fix this of course (#577), there are workarounds for this for now.

Having the above statements, change the statement in the subgroups 
(/unicorex/servers and /unicorex/users), so that their condition is not 
simply 'true', but explicitly requires membership in the current group. 
I.e. group contains '/unicorex/servers' and analogical for /unicorex/users.


Thanks for reporting this!
Krzysztof