[Fedora-directory-users] Proposed new features for 1.3

[Rich Megginson]

Andrey Ivanov wrote:
>
>                * support of other virtual attributes generated "on the
>         fly"
>
>            Can you explain this a little more?
>
>
>         For example, the memberOf attribute now generated by memberOf
>         plugin and written into the db could be generated dynamically.
>
>     For the particular case of memberOf, we decided against using
>     virtual attributes.  One reason is that it's harder to do
>     filtering/indexing on virtual attributes e.g. supporting searches
>     like (memberof=somegroup).
>
> Yes, i remember this reasoning - i was following quite closely the 
> development of this plug-in as it was sine qua non for our production 
> environment...
>  
>
>
>         The attributes like entryLevelRights and attributeLevelRights
>         are already created dynamically, nsRole/CoS also (one of the
>         main drawbacks of the roles is that they are only applicable
>         to a sub-tree).
>
>     One of the drawbacks of groups is that they do not apply to the
>     sub-tree - makes it difficult in general to replicate them.
>      Roles/CoS are scoped along with the data they apply to, so they
>     go along with replication quite easily.
>
> Yep.You're talking about the drawbacks concerning the difficulty of 
> the code development.  But for us the sub-tree application that was an 
> essential limitation of Roles - we couldn't use it to make the same 
> thing as memberof, that's why i was looking forward eagerly for the 
> memberof  plugin...
Do you want to do something like this
dc=example,dc=com
+ou=people
+ou=roles
++cn=my role

And have cn=my role be a role that applies to users under ou=people?  
e.g. by adding a roleSubtree: ou=people,dc=example,dc=com to the role 
definition?
>
>
>         I'm talking about this type of "virtual" attributes generated
>         by some filters or regular expressions or plug-ins, maybe
>         creation of some sort of framework or mechanism to generalize
>         the creation of such attribiutes.
>
>     There already is a framework, but not many want to delve into the
>     C code.
>
>     Can you provide some examples of what you mean?
>
> For example, automatic generation of a virtual attribute describing 
> the location (or type) of the person by applying regex to his/her 
> telephoneNumber (first n digits). But then again you are right about 
> indexing and filters with these attributes... Another example: in our 
> production environment we have a "ou" attribute containing the DNs of 
> the units where the person belongs. It would be nice to convert it 
> automatically to an attribute "displayOu" with slashes instead of ",ou=":
>
> ou: ou=lpp,ou=lab,ou=dgar,ou=dg,ou=organisation,dc=example,dc=com
> displayOu: LPP/LAB/DGAR/DG
>
> Today we are using scripts. This type of attribute conversion can 
> easily be made inside an application if you write it internally, 
> otherwise one needs to add this type of "converted" attributes...
Ok.  So something like CoS, but with a couple of additional attributes:
cosDestinationAttribute - grab the value from cosAttribute, but write to 
this attribute instead
cosRegex - apply this regex to the value e.g.
cosAttribute: ou
cosDestinationAttribute: displayOu
cosRegex: s|ou=(\S)+,ou=(\S)+,ou=(\S+),ou=(\S+)|\1/\2/\3/\4/|

It would be difficult to create indexes on these (e.g. if you wanted to 
do searches like (displayOu=LPP/*)

Something like that would be useful for posix homeDirectory too
cosAttribute: uid
cosDestinationAttribute: homeDirectory
cosRegex: s,(.+),/home/\1,
>
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20090415/846f7dab/attachment.bin>