Last modified: 2014-10-27 19:15:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T16801, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 14801 - Global deleted image review for Commons admins
Global deleted image review for Commons admins
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal enhancement with 32 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://meta.wikimedia.org/wiki/Global...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-12 20:33 UTC by Christian Nagy
Modified: 2014-10-27 19:15 UTC (History)
36 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Basic patch by ChrisiPK (11.29 KB, patch)
2009-03-13 19:34 UTC, ChrisiPK
Details
Patch for Special:Undelete (2.56 KB, patch)
2009-09-22 02:29 UTC, ChrisiPK
Details
Patch (unreversed, with unified diff) for Special:Undelete (3.81 KB, patch)
2009-09-22 22:23 UTC, ChrisiPK
Details
Patch for Special:Undelete built against trunk (2.27 KB, patch)
2009-09-24 16:23 UTC, ChrisiPK
Details
Patch for Special:Undelete built against trunk (fixed) (2.86 KB, patch)
2009-09-24 18:56 UTC, ChrisiPK
Details
Per namespace permissions for User.php (6.52 KB, patch)
2011-07-11 19:11 UTC, Bryan Tong Minh
Details

Description Christian Nagy 2008-07-12 20:33:47 UTC
After a successful poll on Meta (http://meta.wikimedia.org/w/index.php?title=Metapub&oldid=1082758#Global_deleted_image_review) it should be time to take further measures. There is clear community consensus to adopt the policy mentioned above (http://meta.wikimedia.org/wiki/Global_deleted_image_review) and therefore I suggest to create a global group called "Commons admins" (or similar) with the permission to view deleted images. 

Thank you,
Christian Nurtsch
Comment 1 Alexandre Emsenhuber [IAlex] 2008-07-12 20:37:46 UTC
Global groups are created by stewards, so i think your request should be on meta, not here.
Comment 2 Victor Vasiliev 2008-07-12 20:55:39 UTC
(In reply to comment #1)
> Global groups are created by stewards, so i think your request should be on
> meta, not here.
> 

Yes, but they are not able to limit it per-namespace (that's another disadvantage of Werdna's system :()
Comment 3 Alex G 2008-07-13 05:05:41 UTC
Sorry, there appears to be some confusion as to where we should go next with this. Should a request be made to Stewards that a global usergroup be made for Commons admins? Are we waiting on anything on the tech side before this request can be made?

Thanks for your time.

[[User:Giggy]]
Comment 4 Bryan Tong Minh 2008-07-13 17:50:04 UTC
Reassigning to Gmaxwell who has The Patch that would allow per namespace settings.

Comment 5 Thomas Goldammer 2008-07-21 09:37:04 UTC
Please implement this only *after* image oversighting. (And let the wikis some months time afterwards to oversight images that need to be.) Commons sysops are not globally elected people or trusted on any wiki or even known.

Th.
Comment 6 BT 2008-07-23 09:29:38 UTC
(In reply to comment #5)
> Please implement this only *after* image oversighting. (And let the wikis some
> months time afterwards to oversight images that need to be.) Commons sysops are
> not globally elected people or trusted on any wiki or even known.
> 
> Th.
> 

See the Meta poll for how this line of argument was dealt with.  As far as the users in the Meta discussion were aware, this feature would be implemented as soon as the poll was finished.  Please don't try to overturn the discussion at Meta by appealing to the devs.  
Comment 7 Thomas Goldammer 2008-07-23 20:58:08 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Please implement this only *after* image oversighting. (And let the wikis some
> > months time afterwards to oversight images that need to be.) Commons sysops are
> > not globally elected people or trusted on any wiki or even known.
> > 
> > Th.
> > 
> 
> See the Meta poll for how this line of argument was dealt with.  As far as the
> users in the Meta discussion were aware, this feature would be implemented as
> soon as the poll was finished.  Please don't try to overturn the discussion at
> Meta by appealing to the devs.  
> 

Please explain where in the policy this is dealt with, I don't find anything about image oversighting there. Don't expect the devs to read all the megabytes of discussion to find that. Thanks.
Comment 8 Mike.lifeguard 2008-07-27 12:52:05 UTC
Folks, this is for discussion of technical implementation - objections to the proposal should go on-wiki. Consensus to implement this has already been established; we await only implementation, which requires developer intervention to create a view-deleted-images-only right so Steward may assign it to Commons sysops. Unless your comment furthers that, it should go on-wiki.
Comment 9 Alex G 2008-07-27 23:43:26 UTC
(In reply to comment #8)
> Folks, this is for discussion of technical implementation - objections to the
> proposal should go on-wiki. Consensus to implement this has already been
> established; we await only implementation, which requires developer
> intervention to create a view-deleted-images-only right so Steward may assign
> it to Commons sysops. Unless your comment furthers that, it should go on-wiki.
> 

As per some of the above, Gmaxwell should be implementing it (soon).
Comment 10 Brion Vibber 2008-07-30 23:32:18 UTC
Best system would be a deletion queue, such that things that don't *need* to be hidden from the whole universe forever don't have to be.
Comment 11 Mike.lifeguard 2008-08-07 00:33:41 UTC
(In reply to comment #10)
> Best system would be a deletion queue, such that things that don't *need* to be
> hidden from the whole universe forever don't have to be.
> 

I may be misunderstanding you, but this wouldn't solve our problem. The problem is that Commons admins sometimes need to see deleted image-namespace content on other wikis. The point of deleting images is that they aren't viewable by those who shouldn't be viewing them - up to now, that has included sysops on the relevant wiki; we want to include Commons sysops in that group of "people who should be able to see deleted images."
Comment 12 Mike.lifeguard 2008-12-28 21:58:26 UTC
I see the 'reviewed' keyword - is that accurate? If the patch has been reviewed, can't it be committed then?
Comment 13 Christian Nagy 2008-12-30 23:31:51 UTC
Right, replaced this one by 'patch' as it has not yet been reviewed (I don't even know if the patch is ready). Something like 'community approved' would be more precise.
Anyway... Go for it!
Comment 14 Platonides 2008-12-30 23:42:49 UTC
Where's that patch?
Comment 15 Mike.lifeguard 2008-12-31 02:38:38 UTC
(In reply to comment #14)
> Where's that patch?
> 

I guess it's trivial to "just do it", but Brion wants it done /properly/ so we wait. Gmaxwell has promised to do it though.
Comment 16 Huib abigor Laurens 2009-03-05 21:53:30 UTC
Is there a progress update?
Comment 17 ChrisiPK 2009-03-13 19:34:53 UTC
Created attachment 5927 [details]
Basic patch by ChrisiPK

I've been playing around with the code and this is what I came up with. I'm not saying it's perfect, but it works fine for me. Maybe this will give people a few ideas or maybe someone can make this better/safe/whatever.

What it does: It adds the user rights viewdeletedarticle, viewdeleteduser, viewdeletedproject, viewdeletedfile, viewdeletedsysmsg, viewdeletedtemplate, viewdeletedhelp and viewdeletedcategory, which enable you to give out per-namespace rights to view deleted content.
What it does not (yet) do: It does not give you a restore link when you are allowed to view something based on these rights. It does not give you a search box when accessing Special:Undelete without a target parameter. To work it, you must access Special:Undelete?target=Page_name_here.

Regards,

ChrisiPK
Comment 18 Platonides 2009-03-13 23:56:25 UTC
I don't like that it created one permission per namespace, which then lead to those giantic switches.
What about $allowed = !$wgUser->isBlocked() && $wgUser->isAllowed( "viewdeletedns" . MWNamespace::getSubject( $target->getNamespace() ) . "andtalk" ); ?
Comment 19 Mike.lifeguard 2009-03-20 17:36:16 UTC
Removed shell keyword as there's nothing to do on shell ATM - we're still waiting on Greg's patch.
Comment 20 Huib abigor Laurens 2009-06-15 18:03:25 UTC
Any update so far? 
Comment 21 Chad H. 2009-06-15 18:12:28 UTC
(In reply to comment #18)
> I don't like that it created one permission per namespace, which then lead to
> those giantic switches.

Yes, I can't possibly see something like that getting applied to trunk.

> What about $allowed = !$wgUser->isBlocked() && $wgUser->isAllowed(
> "viewdeletedns" . MWNamespace::getSubject( $target->getNamespace() ) .
> "andtalk" ); ?

You're still having to add all those rights, even if you're not switch()ing over them.
Comment 22 Platonides 2009-06-15 20:22:15 UTC
What do you mean by 'adding all those rights'?

I just simplified ChrisiPK's switch with a one-liner, 
summarising his 8 rights with a templated permission 
viewdeletedns{$number}andtalk

It might be preferable to not join subject and talk view 
deleted permissions.
Comment 23 Maarten Dammers 2009-07-19 21:52:32 UTC
Any update on this one? Isn't this just the "browsearchive" right limited to ns 6 and maybe 7?
Comment 24 Rocket000 2009-08-29 08:46:39 UTC
I think it will take some interface changes as well since access to Special:Undelete is needed to view anything, but that won't work if you don't have the rights to restore. At the very least the "Restore revisions" box (where you can add a comment when restoring) along with the checkboxes next to each revision needs to be hidden. The title of the page "View and restore deleted pages" would also have to change.

And what about "deletedhistory"? (Don't really know the differences between them or why they're separate.)
Comment 25 Platonides 2009-08-30 12:46:32 UTC
It seems to be already taken into account. Look at UndeleteForm::$mAllowed.
If you don't have the undelete right, you can view the deleted page but the 
restore options aren't shown.

Comment 26 ChrisiPK 2009-09-22 02:29:50 UTC
Created attachment 6569 [details]
Patch for Special:Undelete

New patch for MediaWiki 1.15.1, now with the right "view-deleted-ns-<namespace number goes here>". This makes the switches from the old patch obsolete and allows users to add the right for non-default namespaces.

Please note: This is still only a patch for Special:Undelete. I still haven't found out where the view/undel links are added; pointers are appreciated.
Comment 27 Platonides 2009-09-22 20:23:47 UTC
1. The patch is reversed.
2. Use unified diff when possible.
3. By removing 'deletedhistory', and the part of "!$wgUser->isAllowed( 'deletedhistory' )" you're allowing everyone to see the deleted history.
4. Why are you removing the 1143,1155d1126 and 1195,1200d1165 chunks?
Comment 28 ChrisiPK 2009-09-22 22:23:03 UTC
Created attachment 6576 [details]
Patch (unreversed, with unified diff) for Special:Undelete

(In reply to comment #27)
> 1. The patch is reversed.
> 2. Use unified diff when possible.
> 3. By removing 'deletedhistory', and the part of "!$wgUser->isAllowed(
> 'deletedhistory' )" you're allowing everyone to see the deleted history.
> 4. Why are you removing the 1143,1155d1126 and 1195,1200d1165 chunks?
> 

1. Indeed it is, sorry about that. I still haven't completely mastered the diff tool.
2. I think I found the relevant option, the new patch should be "unified".
3. As you already noted, the patch is reversed. I removed the need for the deletedhistory permission in SpecialPage.php as this prevents users from viewing the page unless they have this right (which not everyone with view-deleted-ns-# might). That is why I added a check in SpecialUndelete.php, see the new patch at @@ -625,6 +637,10 @@.
4. Once again, the patch is reversed, so I am not removing them, but adding them. They take care of the newly introduced variable mAllowedView, which determines whether you are allowed to view the revision (unlike mAllowed, which determines whether you are allowed to restore it).

Best Regards and sorry for the double patch.
Comment 29 Brion Vibber 2009-09-23 20:14:37 UTC
Couple quick notes...

The patch doesn't apply cleanly against development trunk; lots of stuff has changed internally since 1.15, so this'll be a lot easier to get merged if it's rebuilt against trunk instead of a release branch.

I also see some code duplication, copying portions of the UI output between the can-restore and can't-restore cases. This is easy to do the first time around, but makes code maintenance harder -- the copies can get out of sync easily, and generally just clutter the codebase. I would recommend merging the two cases together; just don't output the form fields when they won't be needed.
Comment 30 ChrisiPK 2009-09-24 16:23:22 UTC
Created attachment 6579 [details]
Patch for Special:Undelete built against trunk

New patch, built against current trunk. This is considerably smaller because the trunk already has a variable mCanView, which basically does what I was doing with mAllowedView.

Also note that this still does not provide the "undel/view" links for deleted revisions as I still have not found out where those are created.

Regards!
Comment 31 ChrisiPK 2009-09-24 18:56:16 UTC
Created attachment 6580 [details]
Patch for Special:Undelete built against trunk (fixed)

Yet another patch (sorry for spamming you). This fixes a null pointer exception when accessing Special:Undelete without the undelete right and enables viewing of files. Note: This also enables viewing of files when user has the deletedcontent right - I assume this was intended anyway, right?
Comment 32 Krinkle 2010-05-01 03:24:01 UTC
Ahm... it's been a while.

I often find myself in situations to wait hours or days for an admin at a local wiki.

What's the progress on this ?
Comment 33 Platonides 2010-05-01 11:33:01 UTC
I would prefer this to have this dependant of a Title->userCan(), and having a way to set per namespace $wgGroupPermissions in a sane way.
Comment 34 Bryan Tong Minh 2010-07-09 17:33:47 UTC
(In reply to comment #33)
> I would prefer this to have this dependant of a Title->userCan(), and having a
> way to set per namespace $wgGroupPermissions in a sane way.

We are talking about global groups, so $wgGroupPermissions seems irrelevant. Your suggestion though would imply implementing per-namespace group permission support in CentralAuth.

On an unrelated note a sane way for $wgGroupPermissions to support per-namespace permissions is to allow an array as argument, e.g.

 $wgGroupPermissions['sysop']['deletedhistory'] = array( NS_FILE => true );

In any case I think setting permissions per-namespace is the way to go, rather than creating per-namespace permissions.
Comment 35 Krinkle 2011-03-16 00:21:22 UTC
*bump*

Commons is getting fuller and fuller, more wikis moving to commons, more work.

It's been 3 years since it was accepted through a global-vote on Meta.

Bryan's suggestion appears to be a plausible solution. Altough I don't know a lot about the permissions and authentication in core and CentralAuth, it sounds like something that shouldn't be too hard.

Whatever uses $wg*Permissions checks if either the value itself or the current namespace array item in that value is true.

Can someone write a patch for this ? Do we need to update most/all usages of User->isAllowed / userCan() for addition/replacement with Title->userCan, or can it be implemented in there ?

Even if you can't write a patch, adding some notes would be great so others can pick them up.
Comment 36 Platonides 2011-03-16 22:42:36 UTC
Only those in SpecialUndelete would need to be changed, but there are a number of them.
Comment 37 p858snake 2011-04-30 00:09:44 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 38 Krinkle 2011-07-04 20:33:09 UTC
The backlogs in Commons are piling up as far back as 2004 with review of moves from other projects to Wikimedia Commons.

Local wikis are refusing to delete images because the moves haven't been reviewed, if they would delete them (clean up), it is likely a Commons sysop may have to request temporary undeletion in order to review. This is taking hours/days/weeks for a single images, simply unworkable.

with over 6 years of backlog and 3 years of waiting for an implementation I think it's time we get this under serious consideration and write out a road map of what needs to be done. An estimation at the very least because the work-arounds are killing at the very least and no where even near motivating or collaborative.

Needed end-result:
* There is a global user group which is allowed to view deleted files and their file-page history on all wmf-wikis.

Technical aspects:
* [x] Global groups
* [_] Per namespace rights
* [_] Per namespace rights support through global rights

Making for triage, waiting for assignee and review of patch.
Comment 39 ChrisiPK 2011-07-04 20:38:49 UTC
Just a quick note, because you asked for patch review: That patch was more of a quick first attempt at hacking on my part, to give people an idea, where to put this. In the mean time, we also have Deleted Revisions, which would likely also need to be patched. That patch will definitely have to be re-written from scratch, as it was already insufficient at time of build and might now be useless, because the code base has changed.
Comment 40 Krinkle 2011-07-04 20:39:31 UTC
(In reply to comment #34)
> (In reply to comment #33)
> > I would prefer this to have this dependant of a Title->userCan(), and having a
> > way to set per namespace $wgGroupPermissions in a sane way.
> 
> We are talking about global groups, so $wgGroupPermissions seems irrelevant.
> Your suggestion though would imply implementing per-namespace group permission
> support in CentralAuth.
> 
> On an unrelated note a sane way for $wgGroupPermissions to support
> per-namespace permissions is to allow an array as argument, e.g.
> 
>  $wgGroupPermissions['sysop']['deletedhistory'] = array( NS_FILE => true );
> 
> In any case I think setting permissions per-namespace is the way to go, rather
> than creating per-namespace permissions.

I agree. So the userright-key in the user-group array in $wgGroupPermissions is either boolean or an array of namespace-ids with booleans.

So in the userCan function needs the option (or requirement) to specify a Title object.

The Title-class currently has permission-related functions, how usable are they for this bug ?
Comment 41 Bawolff (Brian Wolff) 2011-07-04 21:43:40 UTC
> 
> The Title-class currently has permission-related functions, how usable are they
> for this bug ?

The userCan hook already gets passed a title. One could just simply make an extension using that hook. A really hacky implementation could be done in about ten minutes. (userCan hook that just checks local group membership at commons [hey we already do cross-db access for global usage], and lets people read if they are a sysop over there). Admittedly that'd be a bit hacky [Normally rights give people rights to do stuff, not group membership].
Comment 42 Krinkle 2011-07-08 21:54:41 UTC
(In reply to comment #41)
> > 
> > The Title-class currently has permission-related functions, how usable are they
> > for this bug ?
> 
> The userCan hook already gets passed a title. One could just simply make an
> extension using that hook. A really hacky implementation could be done in about
> ten minutes. (userCan hook that just checks local group membership at commons

This bug (or rather part of it, we should split it) requests to:
1) Have the ability to set permissions per namespace
2) Have the globally
3) Set some in NS_FILE for commons admins. This last part could either be cross-wiki read, or as a global group. I don't think having to manually add as global group is that big a deal though. Could be done by a wiki bot, that's all very minor details. The problem is having these permissions work and being able to set them from LocalSettings and for global groups.

When I referred to the usefulness related to this bug I meant point 1 and 2.
Comment 43 Bryan Tong Minh 2011-07-11 19:11:37 UTC
Created attachment 8772 [details]
Per namespace permissions for User.php

Patch that adds support for per namespace permissions in User.php. Next step would be to patch User::isAllowed() and Title::getUserPermissionsErrors().
Comment 44 Krinkle 2012-04-12 15:06:21 UTC
Comment on attachment 6580 [details]
Patch for Special:Undelete built against trunk (fixed)

marking patch obsolete as it no longer applies cleanly to trunk and is meant for bug 29780.
Comment 45 Krinkle 2012-04-12 15:06:25 UTC
Comment on attachment 8772 [details]
Per namespace permissions for User.php

marking patch obsolete as it no longer applies cleanly to trunk and is meant for bug 29780.
Comment 46 Tomasz W. Kozlowski 2012-08-21 15:25:43 UTC
It's /just/ four years since the bug was reported, and a community consensus was granted. Are there any updates on the status of this bug? Is it ever going to be fixed?
Comment 47 Nemo 2012-08-21 15:58:31 UTC
(In reply to comment #46)
> It's /just/ four years since the bug was reported, and a community consensus
> was granted. Are there any updates on the status of this bug? Is it ever going
> to be fixed?

I suspect that, however difficult it may be, it's actually easier to get consensus for a global group with deletedtext permission on all namespaces than to get this bug fixed. If there was consensus for that, stewards could easily create the group and add any Commons admin who needed it. Beware, this is not the place to discuss it, you have to change [[m:Global deleted image review]] (and get it approved).
Comment 48 matanya 2012-08-21 16:03:46 UTC
I'll create a global group on my wiki and test this. I'll be back with answers.
Comment 49 Krinkle 2012-08-24 14:44:51 UTC
(In reply to comment #48)
> I'll create a global group on my wiki and test this. I'll be back with answers.

Don't bother. That will work just fine. We create that kind of global groups all the time.

Moving this bug back to the Wikimedia product, because this is just a request for configuration, not MediaWiki software implementation. The implementation of features that make this possible are already tracked and set as blockers for this bug:
* bug 29780
* bug 29781
Comment 50 Tomasz W. Kozlowski 2012-08-24 15:19:58 UTC
This isn't right. The original request asked for creating a global group for Commons administrators with the rights to see deleted content only from the File: and File talk: namespaces (numbers 6 and 7). 

Now you are changing this request into one that grants Commons sysops the rights to view deleted content from all namespaces -- and there wasn't community consensus for that.

Please revert or create & lead another RFC on Meta asking the community to create a group with such permissions.
Comment 51 Benjamin Chen 2012-08-24 15:28:29 UTC
(In reply to comment #50)

> Now you are changing this request into one that grants Commons sysops the
> rights to view deleted content from all namespaces

Where?
Comment 52 Tomasz W. Kozlowski 2012-08-24 15:30:06 UTC
(In reply to comment #51)

> Where?

Here.
Comment 53 Benjamin Chen 2012-08-24 15:33:43 UTC
(In reply to comment #52)
> (In reply to comment #51)
> 
> > Where?
> 
> Here.

Please...

Bug 29780 and bug 29781 specifically said per-namespace permission, and Nemo_bis's comment #47 also meant that it is easier to get a '''new''' consensus onwiki. Maybe I missed out something but I don't see anyone changed the bug to a request of global deletetext.

So could you kindly point that out.
Comment 54 Tomasz W. Kozlowski 2012-08-24 15:47:21 UTC
As I understand, this bug was originally asking (though not very clearly) to add per-namespace permissions to the core of MediaWiki, and then assign 'deletedhistory' and 'deletedtext' for namespaces 6 and 7 to a global group including Commons administators only. 

I also understood comment #47 to suggest that getting a new community consensus to assign 'deletedhistory' and 'deletedtext' for all namespaces to the global Commons administrators' group as the way that this bug should be resolved, and wanted to point out that the community consensus from 2008 was only to grant these rights on the two aforementioned namespaces.

I am sorry for not being clear enough; I now see that this is only waiting for bug 29780 to be fixed, and then it will truly be only a configuration matter. And thanks for your patience, Benjamin ;-))
Comment 55 Krinkle 2012-08-24 16:03:42 UTC
-shellpolicy: This has already been agreed on, no policy.

-shell: This can't be acted upon yet, because it has not been implemented in mediawiki core (bug 29780) and in CentralAuth (bug 29781) yet.
Comment 56 Nemo 2012-08-25 08:18:26 UTC
Readding shellpolicy to make clear that this is on hold and waiting for (multiple) clarifications: *given* the single-namespace only requirement (not in discussion [yet]), several implementations have been proposed and it's not clear which one we're going to pursue.
If bug 29781 was the only way, this should be RESOLVED INVALID because bug 29781 would make it a matter of steward requests, not of site configuration.
Comment 57 Krinkle 2012-08-25 15:04:06 UTC
Removing shellpolicy again. This is not in need of further clarification. The proposal was very clear and straight forward about how the implementation was to be done (deletedtext in the file namespace, globally).

Yes, once done it will probably be implementable by stewards. This is just a tracking bug because it is a major thing that needs software to be written. The actual resolution of it probably doesn't require wmf-config changes.
Comment 58 Andre Klapper 2013-04-25 16:43:31 UTC
Lowering priority, as bug 29780 and bug 29781 need to get fixed first.
Comment 59 Gerrit Notification Bot 2014-08-18 18:16:15 UTC
Change 154868 had a related patch set uploaded by Legoktm:
SpecialUndelete: Check permissions on a per-page basis

https://gerrit.wikimedia.org/r/154868
Comment 60 Kunal Mehta (Legoktm) 2014-08-18 18:29:12 UTC
I think restructuring the entire permissions system would be nice, but I doubt anyone is planning to do that for the next few years.

So I think bawolff's comment 41 is the best and easiest way to move forward. I uploaded a patch which changes Special:Undelete to check per-page restrictions, allowing us to set per-namespace restrictions in the wmf-config:

$wgHooks['TitleQuickPermissions'][] = function ( Title $title, User $user, $action, &$errors, $doExpensiveQueries, $short ) {
	return ( !in_array( $action, array( 'deletedhistory', 'deletedtext' ) ) || !$title->inNamespaces( NS_FILE, NS_FILE_TALK ) || !$user->isAllowed( 'globalimagereview' ) );
};

Then we just create a global group that has the "globalimagereview" userright.
Comment 61 Gerrit Notification Bot 2014-09-18 23:44:26 UTC
Change 154868 merged by jenkins-bot:
SpecialUndelete: Check permissions on a per-page basis

https://gerrit.wikimedia.org/r/154868
Comment 62 Gerrit Notification Bot 2014-09-24 05:55:55 UTC
Change 162546 had a related patch set uploaded by Legoktm:
Add "viewdeletedfile" userright for global deleted image review

https://gerrit.wikimedia.org/r/162546
Comment 63 Gerrit Notification Bot 2014-09-25 18:38:31 UTC
Change 162546 merged by jenkins-bot:
Add "viewdeletedfile" userright for global deleted image review

https://gerrit.wikimedia.org/r/162546
Comment 64 Kunal Mehta (Legoktm) 2014-09-25 18:55:52 UTC
On a technical level this is now implemented, marking as fixed accordingly. The userright is now grantable by stewards, but it won't start working until 1.25wmf1 is deployed to all sites (it hit group0 today, will take a week).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links