Last modified: 2007-07-11 17:31:10 UTC
It is impossible to implement read permissions acceptably if arbitrary PHP logic can determine whether the user can read the result. To quote Yurik, who's currently trying to deal with this for the API, "when getting 5000 articles, and only after everything is queried to discover that the user has no right to see it is horrible". In particular, it's impossible to implement any kind of paging reasonably if you can't work the readability conditions into the query, since then you have to make an arbitrary number of additional queries to fill out the page. In the worst case, there may be a huge number of pages of which only a couple (if any) are readable, requiring the entire table to be queried piecewise. Therefore we need to not call Title::userCan for read, and instead allow only read restrictions that can be used in database queries. In particular, we currently have only a read whitelist. We should add to this per-namespace read restrictions, like $wgNsGroupPermissions[ns][group][right]. Those should suffice for almost all purposes. It might be worth considering allowing use of the protection function for read as well as edit and move, but this isn't really particularly necessary: even packages that allow heavy lockdown (e.g., forum software) don't bother with that that I've heard of. They expect you to either delete it or move it to a hidden forum (namespace). We *do* need to incorporate all these protections into the core software, because otherwise we'd have to provide fragile hooks for modifying every single read query. Read permissions could, if there are still objections to working with them, be treated like PostgreSQL: let the people maintaining them maintain them, and don't expect anyone else to do more than maybe make a note when they add something that ignores them. Or if there are *really* still philosophical objections from Brion to having this kind of thing in core, we should just implement this anyway sans the ability to use unreadable namespaces, and make it clear that the read permission does not and cannot ever affect the ability to view lists of titles. But I think that's excessive given the general utility to all sorts of third parties of hiding namespaces.
I think some sites may want to have "per user read permissions" instead of using the built-in groups. This is totally OK if the site supplies a list of accessible namespaces for the given user: wfGetUserNsReadRights() would return a whitelist of allowed namespaces: [0,1,6,7] or [] (no NS are readable) The default implementation would return the list of all namespaces available to the current user, and a hook would be able to override that list.
Paging would be based on presence of entries, not on readability of their contents.
Okay, I'll take that as "make it clear that the read permission does not and cannot ever affect the ability to view lists of titles".
