Callers analysis

Title::isBigDeletion can be called by PermissionManager when all of the following conditions are met (plus others not dependent on the code):

• checkActionPermissions is called
• $action is 'delete'
• $rigor is not QUICK

checkActionPermissions is private, called by getPermissionErrorsInternal (also private). $action and $rigor are passed through, so we're now looking for calls to getPermissionErrorsInternal with $action delete and $rigor QUICK.

There are three methods calling getPermissionErrorsInternal:

• checkActionPermissions. This is for checking multiple rights, but since every call specifies an action literally and none of them are 'delete', we can ignore it.
• getPermissionErrors
• userCan

The last two are public and pass $action and $rigor through. So we need to audit those.

getPermissionErrors

No usages as a string literal found out of tests. See codesearch for all calls.

Calls with literal 'delete'

• SpecialMovepage::doSubmit (twice): this should go through the new DeletePage regardless, so it should be fine if we move the check in there
• Ext:DynamicPageList, DPL::deleteArticleByRule: ditto
• Ext:Nuke, SpecialNuke::doDelete: ditto
• Ext:Translate, SpecialPageTranslationDeletePage::doBasicChecks: this one is a tad more complicated, because actual deletion happens via the job queue and is performed by a system user (not the one whose permissions are checked when using PermissionManager). I'd like to better understand the use case here. If it's just "basic checks", perhaps it doesn't need to know about big deletion. Also, since it's deleting a single page and "native" deletion can also use the jobqueue, deletion might happen outside of the job.

Calls with variable action

• Action::checkCanExecute: a bit hard to tell what could be using this and how. But I'm going to assume that if it's used for the UI the bigdelete check is unnecessary, and the code could use DeletePage otherwise.
• UserAuthority::internalCan: more on this later.
• Flow, Workflow::getPermissionErrors: only used within the same class with rigor QUICK, thus ignoring.
• NSFileRepo, UserCan::process: I'm very confused by this code. It doesn't seem to even care about the action or anything, so I guess it will continue to work fine.
• RightFunctions, ExtRightFunctions::ifpageallowed: exposes permission data via a parser hook, so it all depends on how users are using this. Since it appears to be totally unmaintained, I'll ignore that.
• BlueSpiceFoundation, Api::checkPermission: called twice by ::checkPermissions. Permissions to check are determined by ::getRequiredPermissions(), and nobody is using "delete".
• Wikibase, SubmitEntityAction::getPermissionStatus: private method, only called for "edit".
• Wikibase, WikiPageEntityStorePermissionChecker::getPermissionStatus: possible values for the action are determined by ::getMediaWikiPermissionsToCheck, and "delete" isn't among them.
• Wikibase, EditEntityAction::showPermissionError: never called with "delete".

As for UserAuthority::internalCan: this is a private method used by definitelyCan, authorizeRead, and authorizeWrite. The permission is passed through, so we'd need to check usages of those methods.

definitelyCan

• ContentModelChange::checkPermissions: never called with "delete"
• MovePage::checkPermissions: never called with "delete"
• FileDeleteForm::showForm: that's deletion-related code that I'm refactoring as part of T288242. I'll obviously make sure that nothing breaks.
• ApiQueryInfo: this exposes permissions to users, so something could break. It's up to editors to make sure that this isn't the case, so we should announce this on Tech/News too.

authorizeRead

• RevisionRecord::userCanBitfield: never called with "delete"
• ApiQueryInfo: same as above
• ApiBase::checkTitleUserPermissions: only relevant usage is in ApiDelete. But this is also going to be refactored as part of T288242.

authorizeWrite

• FileDeleteForm::execute: also being refactored as part of T288242.
• DeleteAction::tempDeleteArticle: ditto.
• Article::delete: being removed in the upcoming days as part of T288242.
• ContentModelChange::authorizeChange: never called with "delete"
• ApiBase::checkTitleUserPermissions: see above, same as authorizeRead
• MovePage::authorizeMove: never called with "delete"
• MergeHistory::authorizeMerge: never called with "delete"

userCan

Several methods with this name exist, and there are a lot of calls :-( I've filtered them according to the following rules:

• Exclude calls like [dnv]->userCan\(: all of them are calling RevisionRecord::userCan
  • Of these, every occurrence not followed by a space after the opening parentheses isn't relevant, except for ExtRightFunctions::ifpageright, which is the same as the ifpageallowed case above.
  • Of those with a space, I've searched for the ones followed by a single or double quote and then a literal "d" (as everything else is passing some permission that we don't care about).
  • The ones followed by a space but not a quote were analyzed separately, excluding not just quotes but "R" and "F", used respectively for RevisionRecord constants (indicating RevisionRecord::userCan) and File constants (indicating File::userCan)
• itle->userCan\( (calling Title::userCan, removed in 1.36) was checked separately
• The remaining e->userCan\( are all for File::userCan and were ignored

Results for Title::userCan

• SemanticMW, PermissionManager::userCan: it's a homonym class with a homonym method), so any usage should be covered below.
• NSFileRepo, NamespaceList::skip: never called with "delete"
• MultiLanguageManager, SkinTemplateContentActions::process: never called with "delete"
• ApprovedRevs, ApprovedRevs::checkPermission: never called with "delete"

Results for [^dven]->userCan\( ['"]d

• BlueSpiceBookshelf, ApiBookshelfManage::task_deleteBook: calls WikiPage::doDeleteArticleReal immediately, so it can be addressed by switching to DeletePage and letting that handle the permission checks. It will need a hack to determine whether the user lacks permissions based on the status messages, but that's what you get if you want to replace standard messages with verbatim copies of them.
• BlueSpiceSocial, Entity::getActions: I haven't checked deeply what it's used for, but it doesn't seem to delete anything (it's a list of actions that the user can do on a given page), so there shouldn't be any problem (and the maintainers will have a chance to fix that once we deprecate the old behaviour).
• BlueSpiceContextMenu, Delete::shouldList: used for showing links, so no problem I would say

Results for [^dven]->userCan\( [^'"RF]

• PermissionManager::quickUserCan: QUICK rigor, ignoring.
• RevisionRecord::audienceCan: false positive
• LocalFile ::getUploader and ::getDescription: false positives
• SpecialUndelete::isAllowed: no call in that class uses "delete", nothing is extending the class fortunately
• BlueSpiceFoundation, BSTestPermissions::testPermission: it's a test maint script
• BlueSpiceFoundation, Title::userCan: another homonym, should appear in the other search results
• BlueSpiceFoundation, BSApiTasksBase::checkTaskPermissionsAgainstTaskDataTitles: none of the many getRequiredTaskPermissions() methods returns 'delete', nor does getGlobalRequiredTaskPermissions().
• BlueSpiceFoundation, Module::checkPermissions: the only getPermissionKey() method I could find returns "read"
• BlueSpiceRating, PrimaryDataProvider::checkRatingPermission: false positive
• BlueSpiceRating, RatingItem class:
  • 4 occurrences in ::vote(), one of which with "delete". If successful, calls ::deleteRating(), which deletes custom things that are not wiki pages. Nice. Ignoring.
  • ::checkPermission: in the same class it's only used by a method named userCan, which should appear in the other search results. No external usages that I could find.
• BlueSpiceSocial, Entities::task_editEntity: doesn't use "delete".
• BlueSpiceSocial, Entities::task_deleteEntity: used to delete custom stuff, ignoring.
• BlueSpiceSocial, Entity::checkPermission: never called with "delete" (see line 407)
• BlueSpiceSocial, Entity::userCan: homonym, should appear elsewhere in the search results
• CommentStreams, ApiCSDeleteComment::deleteComment: never called with "delete"
• CommentStreams, ApiCSEditComment::executeBody: never called with "delete"
• AbuseFilter, three instances in AbuseFilterChangesList: all false positives
• ApprovedRevs, ApprovedRevs::checkPermission: same as in the Title::userCan section, never called with "delete"
• BlueSpiceExtendedStatistics, Collection::checkPermission: never called with "delete" (see line 117)
• BlueSpiceSocialWikiPage, Stash::task_addFiles: never called with "delete"
• BlueSpiceSocialWikiPage, Stash::task_removeFiles: never called with "delete"
• BlueSpiceUniversalExport, ExportModule::callSubactions: no getPermission() method that I could find returns "delete"
• Echo, EventPresentationModel::userCan: homonym, should appear in the other results
• NSFileRepo, NamespaceList::skip: same as the Title::userCan section, never called with "delete"
• Video, SpecialUndeleteWithVideoSupport::isAllowed: never called with "delete"
• Wikibase, EditEntityAction::showPermissionError: never called with "delete", same as above for the getPermissionErrors case.
• SemanticMW, PermissionManager::userCan: homonym and same as in the Title::userCan section.

Conclusions

I don't see any showstopper or anything that prevents us from moving the logic from Title to DeletePage and make it not be page-wise but deletion-wise, as long as the following things are done/kept in mind:

• The old behaviour should be deprecated: soft deprecation and a mention in the release notes. Hard deprecation is impossible as callers have no way to specify whether they want that code to be executed or not.
• Add a notice to Tech/News once the old code is removed, in particular for the change to ApiQueryInfo behaviour
• It'd be nice if we could migrate the methods listed above that also delete pages to the new DeletePage service
  • I'd like to better understand the code in Translate and see if it can be migrated, too
• Obviously, make sure that deletion-related code in core (DeleteAction, FileDeleteForm, ApiDelete, WikiPage) will still perform the bigdeletion check.