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 roleAnd 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/DGToday 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
<<attachment: smime.p7s>>
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
