On 10/11/06, George Herbert <george.herbert(a)gmail.com> wrote:
Following up from a discussion on unblock-en-l...
How much effort would it be to add an enhancement to treat blocked
user redlink clicks like we currently treat anon user redlink clicks
when anon article creation is disabled?
We're trying to minimize the number of people who are fundamentally
just readers, who click on a redlink and see a block message (mostly
AOL users, but it happens to others). If they click on the "edit" bar
and get it, that's fine, but if the default redlink behavior didn't
show the block message then that would be great.
Thanks.
I don't think it would be appropriate to just say "you can't create
this article because you aren't logged in", when there are more
reasons as well. That would imply to the user that if they *did* log
in, they'd be allowed to create the article, which isn't the case.
They need to be informed that they've been blocked, preferably as well
as any other reasons they can't do stuff.
Tangential question: why is User::isBlocked a public method
altogether? Why not just run everything through a generic
permissions-checker method, and return an array of reasons (rather
than "false" as with User::isAllowed) if that's the answer? That
would ensure consistent handling of blocked vs. other reasons
*everywhere*, which I should think would be desirable. It would also
ensure that people got the full story as to why they couldn't do
something, rather than a single reason of multiple.