[EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED
COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43915>. ANY REPLY
MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG
DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43915
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED Resolution|
|FIXED
------- Additional Comments From [EMAIL PROTECTED] 2007-11-21 03:17
------- I introduced a method Role.isAssignable() and a role
"sitemanager" with a group of the same name. All users have to update
their policies accordingly.
Please test and re-open if this doesn't resolve the issue. TIA!
hmm. i don't like this patch at this point in tíme.
if i understand richard correctly, he has been handing out the admin
role to users, thinking that they are limited to the subtree they are
given. but this opens the hole that a user can browse there and then
call admin usecases to escalate his/her privileges. if this is correct,
read on, otherwise i've misunderstood something, so ignore me.
i think this is basically a documentation bug. what's needed for this
usage scenario is a new role like you introduced, but this is something
that users can do themselves, tailored to their needs. why do we need a
new method (e.g. a *fundamental* change to the AC API), and why should
everyone have to update their policies during code freeze?
sorry if i've had a lot of criticism to offer lately, and not much help,
but i'm drowning in work... i think we should tie up what we have and
not get into any new things that are not really bugfixes.
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
