Thanks all for replies.
This basically means that if a principal has read access in one group and read-write in another, then if the read group comes first, then when a webdav request is made to edit the document, the resource will be streamed to the user in read-only mode. Not desirable in some circumstances... Anyhow, at least I know now how to proceed. thanks again Nick
No, I think you're still misunderstanding.
If you request a document from the server, to read it, that's an action that only requires read privs. So, the server will check to see if you have read privs, and if you do, it'll serve the file. At no point does slide even look to see if you have write privs at all!
If, later, you then want to write the file to the server, it'll check write privs. In that case, the first group won't have that permission, so slide will keep checking the other permissions. It then sees the second group, which does, so it'll let you write the file.
There's no possible way for a file to be served to the user in 'read-only mode' - the protocol just serves the file up, with no other indications of what else the user can do with it.
Now, a client can _also_ use a request for the acl property on a resource to figure out what permissions the user has. So it's possible (though somewhat tricky) to figure out whether the user would be able to write the resource if they tried to. If you did that, you'd find that, since the user is a member of the 2nd group (with write permissions), the ACL will indirectly say that the user DOES have write permissions.
Is this any clearer? Some of this stuff confused me quite a lot when I first tried to figure it out.
Note that writing code to figure out what permissions a user has for a resource, based on the acl property, is quite complex - you'll probably need to read the ACL spec several times before you can do it.
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
