https://bugzilla.wikimedia.org/show_bug.cgi?id=17116
Brion Vibber changed:
What|Removed |Added
CC||br...@wikimedia.org
Status
https://bugzilla.wikimedia.org/show_bug.cgi?id=17116
--- Comment #7 from Andrew Garrett 2009-01-22 04:06:33
UTC ---
Will leave the bug open for a determination of whether this is something we
*want*, or something that needs to be fixed.
--
Configure bugmail: https://bugzilla.wikimedia.or
https://bugzilla.wikimedia.org/show_bug.cgi?id=17116
--- Comment #6 from Jonathan Eisenstein 2009-01-22
04:05:23 UTC ---
Fair enough -- I'll use this as a workaround in code. I think it disagrees with
the documentation which states, "User should be allowed to proceed.
Later functions can ov
https://bugzilla.wikimedia.org/show_bug.cgi?id=17116
--- Comment #5 from Andrew Garrett 2009-01-22 03:58:32
UTC ---
I don't agree that "There is no way for the extension author to declare that it
has no problem with the user having read access, but to also allow the other
security code to r
https://bugzilla.wikimedia.org/show_bug.cgi?id=17116
--- Comment #4 from Jonathan Eisenstein 2009-01-22
03:55:36 UTC ---
If I understand correctly, the result of wfRunHooks() should be the instruction
of whether to continue processing security rules. An extension author can set
the $result
https://bugzilla.wikimedia.org/show_bug.cgi?id=17116
--- Comment #3 from Andrew Garrett 2009-01-22 03:45:16
UTC ---
I'm not sure what the documented behaviour is, but it looks like if you don't
want to force a specific result, then you shouldn't set $result.
--
Configure bugmail: https:/
https://bugzilla.wikimedia.org/show_bug.cgi?id=17116
--- Comment #2 from Jonathan Eisenstein 2009-01-22
03:42:02 UTC ---
I did -- the code causing the original behavior centers on this:
wfRunHooks( 'userCan', array( &$this, &$wgUser, 'read', &$result ) );
if ( $result !== null ) {
https://bugzilla.wikimedia.org/show_bug.cgi?id=17116
Andrew Garrett changed:
What|Removed |Added
CC||and...@epstone.net
--- Comment #1
