Sebastien BARRE wrote:
On the other end, here is a simple question then: what are functions like userCanRead() and userCanEdit() for, if, at the end of the day, they don't guarantee what they are supposed to do ? Either those 2 functions work, either they don't.
False dichotomy. ;)
userCanEdit() should 'work' for pretty much all uses; if it doesn't, that's a bug, please report it.
userCanRead() is limited to enforcing $wgWhitelistRead, which is very very limited in what it can do. It's 100% dependent on $wgWhitelistEdit; if nonauthenticated users were allowed to so much as do render page previews on a sandbox they could read the contents of any page in the wiki. Its sole purpose (and it's awkward even for this) is to make a welcome page and the login page reachable before you log in to a private-access wiki.
If anything's editable, *everything* is viewable. By design, everything is supposed to be viewable anyway; anything else is a hack which gives people an opportunity to log in (at which point they are "in" and have full access).
This is deliberate behavior and not a bug.
In any case, I should not have used "ACL" in the subject, it is way beyond what I would like to do. What I'm talking about here is nothing more than a small layer on top of the ::userCan() functionality to allow users to be in group(s).
[snip]
See the user groups support in 1.5. There are bugs to be ironed out still, and the layout of the tables etc will likely change (comma-separated blob fields are a pain in the butt to work with).
-- brion vibber (brion @ pobox.com)