Thorsten Scherler wrote: [ ... ]
>>> the usecase permissions for tab.acLive are "admin/grant". >>> lenya (as an admin) should be able to commit the second change, even >>> after taking away the edit permission for one of its own group >>> accreditables, as changing ac calls for the "admin" role (which was >>> never touched). that seems like a big bug. >>> >> I reconstruct this ac behavior and i agree with joern. I really can't >> find a reason why an admin user is not able to change ac entries (if for >> the group edit the role edit is denied). The consequence of the first >> transaction should only prevent the user lenya (if he is a member of the >> group edit) from editing the content of a document. > > Hmm, did you try to create another admin user (which is not in the > editor group) and logged in? > > Try http://lenya.zones.apache.org:9999/default/authoring/concepts.html > before the next build with user lenya. -> Access Denied > > Now try with (user: admin, pass: 123456) -> Access Grant > > It looks out the user lenya which is as well member of the editor. > http://lenya.apache.org/docs/1_4/reference/ac.html#Concept > "The order of credentials at a node is important." > Ok i did not realize that the order of the credentials is important. But does that make sense? If I deny editing for the group edit but grant access for the admin group, I think it is more intuitive to assume that an admin user could at least access and modify the node in the site area even as a member of the group edit. > http://lenya.zones.apache.org:9999/default/authoring/links.html > Here I changed the order allowing the admin group first and then deny > the editors. Login with lenya now works like a charm. > > ...and even if we use a slightly different use case it pins down to > http://lenya.apache.org/docs/1_4/reference/ac.html#samples > > If we want to change this see my bugzilla comment. > I read the comment and basically I think we should do the change. But frankly said i do not fully understand the consequences yet. >> >>> the user does not get a meaningful error message, and lenya throws an >>> exception. that is perhaps a small bug, but it needs to be fixed. >>> >> As joern said I think no gui operation should throw an nasty java >> exception. The user should be redirected to some page e.g. the login >> page or getting a meaningful error message. > > Like I stated in the bug, I agree to catch this exception before it > happens asking the user if he wants continue regardless he will get > looked out afterward. If he agrees then yes there should be a redirect > instead of an exception. > +1 jann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
