Page MenuHomePhabricator

B7. Refine deletedtext/deletedhistory
Closed, ResolvedPublic2 Estimated Story Points


Before we were not requiring deletedtext for the main guard against topics on deleted boards. I put up a quick fix for that (, but it's over-restrictive.

We should require the appropriate one for particular cases. Matthias mentioned blocks and RevisionFormatter::processParam, possibly among others.

Often these are granted together, but there are important exceptions. E.g. the 'researcher' group normally does not have 'deletedtext'.


  1. Add a new key to FlowActions alongside 'permissions', e.g. coreDeletePermissions, pointing to the core permissions required. E.g.:

'view-topic-summary' => array(

// ...
coreDeletePermissions = array( 'deletedtext', 'deletedhistory' ),


  1. Similar to above, but use 'permissions' with another key (e.g. PostRevision::MODERATED_CORE_DELETION). This would have to be consulted in addition to the other ones.
  2. Explicitly call $user>isAllowed( 'deletedhistory' ) or $user->isAllowedAll( 'deletedtext', 'deletedhistory' ) directly from various places e.g. TopicBlock.

Event Timeline

Mattflaschen-WMF claimed this task.
Mattflaschen-WMF raised the priority of this task from to Needs Triage.
Mattflaschen-WMF updated the task description. (Show Details)
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
DannyH renamed this task from Refine deletedtext/deletedhistory to B7. Refine deletedtext/deletedhistory.May 6 2015, 8:45 PM
DannyH triaged this task as Medium priority.May 7 2015, 12:03 AM

I thought about some possibilities for this, which I added to the description. I think I prefer #2 or #1 in that order, but would like some feedback.

What's the point of deletedhistory without deletedtext? It kind of makes sense in a MW Core sense, but in Flow the topic title is part of the page text, so you'd have history with absolutely no context.

I guess this would be a nice ideal thing to do, but if we end up doing a backend refactor to contenthandler, we'd get this for free.

If a board is deleted, you would need deletedtext to be allowed to see any topics/post on there (they're equivalent to the page content)
But in order to see history of topics/posts on that deleted board, you would only need deletedhistory (equivalent to the page history)

Yeah, there are certainly some things you should be able to see with just deletedhistory, even if we consider 'topic title' to be content. For example, seeing the fact that board description was edited (without actually seeing the description itself).

We're already using ContentHandler (but there's still legacy variables). But maybe you mean using user-friendly topic page names. That raises a interesting question, if the topic title is in the page name (rather than the UUID), should it be accessible with only deletedhistory? I would think yes. But that's off in the future.

For now, should we:

  • Just leave it (requiring both deletedtext and deletedhistory) and Decline this for now.
  • Try one of the possibilities I put in the description (2?)
  • Something else


Mattflaschen-WMF changed the task status from Open to Stalled.Jun 4 2015, 8:30 PM

Change 217841 had a related patch set uploaded (by Matthias Mullie):
Add config directive 'core-delete-permissions'

Change 217841 merged by jenkins-bot:
Add config directive 'core-delete-permissions'

Checked in beta.
Users see deleted topics in View history as the follows(notice that there are no topic titles):

Admin users see the topic titles:

Upon clicking on the the first link in the View history - the crossed-out deleted topic " 2015-07-03T21:37:30... ", an admin user will see:

Non-admin user will see:

@Etonkovidova: AFAIUI, those history pages seem fine, right?

But it looks like that revision permalink page doesn't properly work when a user isn't allowed to see it. It doesn't expose info, but this is just confusing :p
Submitted as T104843

DannyH added a subscriber: DannyH.