SUL discussion could perhaps be broken off into another thread?
On 8/13/07, Andrew Garrett <andrew(a)epstone.net> wrote:
On 8/13/07, Simetrical
<Simetrical+wikilist(a)gmail.com> wrote:
This much complexity in blocking definitely
isn't a good idea for core.
I'm not sure what's so incredibly complicated about replacing two
arbitrary flags with three or four well-structured, nullable fields.
As far as I can see, you'll reduce the number of flags from four to
two, while increasing the number of fields from three to five or six
or seven or something. That doesn't look like a decrease in
complexity. If you were to ask why we don't replace the two
permission-specific flags (createaccount/email -- the latter not even
being a proper permission) with a generic permission-selection
mechanism that would allow blocking any existing permission the user
has, matched against a global whitelist (no blocking 'read' on
Wikimedia projects!): that might be a good core feature. It would
unify some existing features while fulfilling multiple other feature
requests. But to also allow the permission to apply to individual
pages/users/etc. is unnecessarily complex for core, and arguably not
desirable altogether.
A more detailed proposal of exactly what schema and UI changes will be
made might allow more explicit criticism and countersuggestions.
On 8/13/07, Andrew Garrett <andrew(a)epstone.net> wrote:
It is /possible/ to implement this functionality in an
extension,
using the existing userCan hook. However, I think that, from a
performance perspective, it would be a lot slower to do so (as the
original blocking system check would have to be performed, as well as
that for the improved system.
To which the solution is to adjust hooks so that's not the case.
Ideally, we should probably allow extensions to easily override any
query in the software for exactly this reason, to avoid having to
throw away or repeat queries.