I'm not very familiar with the users/roles handling, but you have to keep the following points in mind:
- The principal properties must be provided. If you add the users by creating a collection in the role folder, you have to make the group-member-set property a live property. As this property will not changeable, many legacy applications, that modify this property will not work anymore.
Have a look at:
http://www.greenbytes.de/tech/webdav/rfc3744.html#principal.properties
- The principals (users) are identified by an URI, so there can be different users with the same name in different user-collections. So you have to create a collection with an unique identifier. If we do so (e.g. let slide generate the collections name by using sequences), it is not easy to get this working.
Regards, Daniel
Michael Oliver schrieb:
Would it be possible to change Roles to work more like Users?
It would be far easier to manage if the /slide/roles/[role] could be managed by adding a collection with the same name as the user you want to add to that role, i.e. /slide/roles/root/root and /slide/roles/root/Ollie would put root and Ollie in the root role, or /slide/roles/user/john and /slide/roles/user/tom to be members of the user role and so forth. The current method of fetching the member list property, appending the new user and proppatch'ng it back is cumbersome and error prone. It would be cleaner and easier to use and easier to program with the client library if the mechanism was the same as adding a user with mkcol to the /slide/users/ collection, yes?
If the group agrees, I will do the patch and submit it. I just don't want to do the work if nobody else thinks it is a good idea.
Michael Oliver
CTO
Matrix Intermedia Inc.
3325 N. Nellis Blvd, #1
Las Vegas, NV 89115
Phone:(702)643-7425
Fax:(520)844-1036
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
