Krishna, try to remove /Slide
Here's how this property should look like in the xml descriptor
(approximately):
<property name="group-member-set" namespace="DAV:" value="<D:href
xmlns:D="DAV:">/users/user1</D:href>" type=""
protected="false">
<permissions />
</property>
' symbol might not be replaced by " but the user's uri should start
from /users.
Yours sincerely,
Andrey Shulinskiy.
> -----Original Message-----
> From: Slide Users Mailing List [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 04, 2004 7:54 PM
> To: [EMAIL PROTECTED]
> Subject: RE: User Authorization based on permissions set to
> role in Slide2 .1
> Importance: Low
>
> James,
> Here is the output of the group-member-set property of
> the role "user". Note the value has lot of empty and tab spaces
>
>
> /Slide/users/user1
>
>
> Java code used to get this property value
> ==============================================================
> ==============
> ===================
> String sPropertyName = "group-member-set"; Enumeration
> enumProperties = webDavResource.propfindMethod(sPropertyName);
>
> ==============================================================
> ==============
> =====================
>
> Krishna
>
>
>
> -----Original Message-----
> From: James Mason [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 04, 2004 4:57 PM
> To: Slide Users Mailing List
> Subject: Re: User Authorization based on permissions set to role in
> Slide2 .1
>
>
> Can you paste the contents of the group-member-set property
> of the user role? If you notice the root user doesn't have
> any explicit rights to the /files node, everything is
> inherited through the root role. My guess is your user isn't
> making it into the role properly.
>
> -James
>
> Krishna Kankipati wrote:
>
> > Jason,
> > I checked the acl for this folder, it looks like this:
> >
> > ACL for /Slide/files/folder1:
> > ------------------------------------------------------------
> > granted to /Slide/roles/user (not protected) (not inherited)
> > DAV:all
> > DAV:write
> > granted to property (not protected) (inherited from
> '/Slide/files')
> > DAV:read-acl
> > granted to /Slide/roles/root (not protected) (inherited from
> '/Slide/')
> > DAV:all
> > granted to all (not protected) (inherited from '/Slide/')
> > DAV:read
> > ------------------------------------------------------------
> >
> > I added my user 'user1' to role called 'user' using
> group-member-set
> > property (also checked it). Since the role 'user' has the
> permissions
> > to write to folder 'folder1', as seen by the ACL output, and there
> > seems to
> be
> > no contradiction to any other ace's in the acl list, I expected my
> > user 'user1' to have necessary permissions to upload a file to
> > 'folder1'. But
> I
> > get 403 forbidden error. I can login as root and using the same
> > command
> can
> > upload a file to 'folder1'. So, I am not sure whats wrong.
> Initially I
> > thought may be the group-member-set is not set properly, so used
> DAVExplorer
> > to do the same with no avail. Do you think I am missing
> something, how
> > do
> I
> > debug this situation?
> >
> >
> > thanks,
> >
> > regards,
> > Krishna
> >
> >
> >
> > -----Original Message-----
> > From: James Mason [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, August 04, 2004 2:34 PM
> > To: Slide Users Mailing List
> > Subject: Re: User Authorization based on permissions set to role in
> > Slide2.1
> >
> >
> > Krishna,
> > Permissions on a role are inherited by the members of that
> role, yes.
> > One thing to check is that your user isn't being denied
> write access
> > but another ACL that's higher in the list. ACLs are checked
> in order
> > and the first one that applies takes precedence. If user1
> is in a role
> > that has been denied the ability to write, and that ACE
> appears in the
> > ACL before the permission that grants write access, user1 will not
> > have write
> access.
> >
> > -James
> >
> > Krishna Kankipati wrote:
> >
> >
> >>Hi Folks,
> >> I am re-posting this mail since I haven't got any
> replies yet. I am
> >>hoping there is some developer there who might have tried to play
> >>around with permissions in Slide2.1M1. My problem is that when I
> >>assign some permissions to a role, those permissions are not
> >>propogated to the users
> >
> > in
> >
> >>that role. If not for permissions what else is the purpose of having
> roles
> >>at all? I am sure it is not just for logical grouping of users. Any
> >>help
> >
> > is
> >
> >>appreciated ......
> >>
> >>thanks in advance ....
> >>
> >>regards,
> >>
> >>Krishna
> >>
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: Krishna Kankipati
> >>>Sent: Tuesday, August 03, 2004 5:47 PM
> >>>To: '[EMAIL PROTECTED]';
> [EMAIL PROTECTED]
> >>>Subject: User Authorization based on permissions set to role in
> >>>Slide2.1
> >>>
> >>>Michael,
> >>> I was searching the mail archive for some help on
> permissions and
> >>>came upon this discussion you were having with some developer which
> seemed
> >>>relevant to my question:
> >>>http://www.mail-archive.com/[EMAIL PROTECTED]/m
> sg05056.ht
> >>>ml
> >>>
> >>>Does slide permissions propogate based on role
> memberships. I mean,
> >>>if I create a role called "role1", and add a user called
> "user1" to
> >>>it, will
> >>>user1 get all the permissions that are assigned to role1.
> I've seen
> >>>in
> my
> >>>tests that although I gave enough "write" permissions to "role1",
> >>>Slide does not allow "user1" to write unless I add the "write"
> >>>permission to "user1" itself. Am I missing something or is
> it a bug.
> >>>What is your opinion on this? I am using Slide 2.1M1 and
> command line
> >>>client to grant permissions to /Slide/files collection.
> >>>
> >>>thanks
> >>>
> >>>regards,
> >>>Krishna
> >>>
> >>>
> >>>Krishna Kankipati
> >>>Software Engineer
> >>>SSA Global
> >>>* 1626 Cole Blvd. Golden, CO 80401, USA
> >>>* 303-274-3027
> >>>Fax: 303-274-3137
> >>>* [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
