Nick Milas wrote:
On 3/7/2011 2:18 πμ, Howard Chu wrote:
> We've been discussing this problem for quite a while. My current
> thinking is that somehow we can use attribute options to help.
> Visually it might be better to associate the option with the original
> attribute, e.g.
> olcAccess:
> olcAccess;x-comment:
> This would require defining a new (and strange) type of attribute
> option though, since the value with the option has no relation
> (syntactically) to the original attribute type.
>
>
Thank you for this discussion.
I think it might not matter which of the two is the implementation, as
long as the "description" (either "olcWhatever;x-comment:" or
"description;x-olcWhatever:") is available and multi-valued for each and
every attribute and if it can easily stay together with the entry
concerned, and easily displayed in relation to it as well (yes, visual
behavior for comments is important!). For example, for olcAccess,
modifying an example from:
http://www.openldap.org/doc/admin24/access-control.html, if we create
the attribute values:
olcAccess: to attrs=member,entry
by dnattr=member selfwrite
description;x-olcAccess: (0) Access rules for attrs: member,entry
description;x-olcAccess: (0) Entered by Nick on 7/12/2012
olcAccess: to dn.children="dc=example,dc=com"
by * search
description;x-olcAccess: (1) Allow search on children of
example.com
description;x-olcAccess: (1) Entered by Nick on 7/12/2012
olcAccess: to dn.children="dc=com"
by * read
description;x-olcAccess: (2) Allow only read on children of com
description;x-olcAccess: (2) Entered by Nick on 7/12/2012
Interleaved values such as above may never be returned by an LDAP Search
operation. Whether it's desirable for a client to reorganize the data to
display as such, I have no opinion.
I note that the accesslog overlay already allows you to track the history of
individual changes to attributes, so recording an "Entered by <name> on
<date>" comment seems both redundant and vague.
we should be able to easily display:
olcAccess: {0}to attrs=member,entry
by dnattr=member selfwrite
description;x-olcAccess: (0) Access rules for attrs: member,entry
description;x-olcAccess: (0) Entered by Nick on 7/12/2012
olcAccess: {1}to dn.children="dc=example,dc=com"
by * search
description;x-olcAccess: (1) Allow search on children of
example.com
description;x-olcAccess: (1) Entered by Nick on 7/12/2012
olcAccess: {2}to dn.children="dc=com"
by * read
description;x-olcAccess: (2) Allow only read on children of com
description;x-olcAccess: (2) Entered by Nick on 7/12/2012
I assume, all the above should be easier and more intuitive to achieve
using the "olcAccess;x-comment:" approach (even if it's more difficult -
as you say - to implement).
--
-- Howard Chu
CTO, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/project/