Page MenuHomePhabricator

Wikibase should handle old revisions with suppressed content gracefully.
Open, HighPublic


MediaWiki allows the content of old revisions to be suppressed (aka "oversighted" aka "rev-deleted"). Wikibase so far bypasses this check and will display the old revision regardless of the suppression flag. With the code being changed to use the new PageUpdater interface for T194729: Allow Wikibase Entities to be stored in alternative slots [MCR], the check is no longer bypassed. However, Wikibase is not prepared to handle revisions with no content, and will then falsely throw BadRevisionException( "No such revision found for $entityId: $revisionId" ).

Expected behavior:

  • When viewing an old revision with suppressed content, Wikibase should display a message saying that the content is suppressed (unless the current user has the necessary rights for viewing suppressed content)
  • When viewing a diff against a suppressed revision, an error message should be shown instead of the diff (unless the current user has the necessary rights for viewing suppressed content)
  • Undo and reset should not work on revisions with suppressed content (unless the current user has the necessary rights for viewing suppressed content)


  • EntityRevision should allow null to be passed for the $entity constructor parameter, and may thus return null from getEntity(). All callers must be surveyed and adapted. A quick search shows about 80 callers.
    • Alternatively, an empty/dummy Entity could be returned. That way, not all callers need to be changed. But not all entity types support an "empty" state. But maybe it would be possible to allow a "stripped" state for all entity types, which would remove as much information as possible from the entity, retaining only required information. This assumes that required information, such as a property's data type, can never contain anything that needs to be suppressed, such as a private phone number of a celebrity.
    • Another option would be to use the content of the a non-suppressed parent revision. But the fact that the content was suppressed would still need to be signaled somehow, perhaps through a field in EntityRevision. Also, no un-suppressed parent may exist.
  • EntityRevision should support privileged access, allowing users with the appropriate permissions to access suppressed content. Revision and RevisionStore use "audience" parameters for this, a similar approach could be used here. Care must be taken to never cache content that is only accessible with privileged access. Again, a flag in EntityRevision may be needed to indicate that the Entity is non-public.

As a last ditch option, the current behavior, namely ignoring content suppression, could be documented and canonized. Users attempting to suppress old content need to be warned about this, then.

Event Timeline

daniel created this task.Jun 29 2018, 10:36 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 29 2018, 10:36 AM
daniel triaged this task as High priority.Jun 29 2018, 10:37 AM
daniel updated the task description. (Show Details)