Deluxe Administrators

Deluxe Administrators are a fictional usergroup that would serve as an extension to the Administrator usergroup. The intention was to come up with a fictional usergroup that would have various tools that Administrators would benefit from when performing administrative tasks, but many of which could be abused easily. In any case, many of the abilities that Deluxe Administrators have could make them more subjected to abuse due to the large scope of influence the rights have.

Inspiration
The inspiration for the fictional usergroup started sometime in late October 2016 when I was thinking about certain abilities that Fandom Staff, Fandom Helpers, and Volunteer Spam Task Force members had that Administrators didn't have. I was toying around with this question as to which abilities I could see being added to the Administrator usergroup, or as a deluxe version of the Administrator usergroup that Administrators didn't have currently.

Indeed, virtually all the abilities that I had in mind were abilities that Administrators either didn't have or abilities that Administrators once had but were removed from the group due to security reasons. But I had a pretty fun time putting together a list of various tools that could be beneficial for experienced Administrators, nonetheless.

Abilities that the Deluxe Administrator usergroup has
Many of the abilities included in the Deluxe Administrator usergroup are abilities that weren't already included in the Administrator usergroup. But there are a few abilities already included in the Administrator usergroup that were subsequently included in the Deluxe Administrator usergroup.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, since all the usergroups that currently have the Quicktools permission also have the Rollback permission, with the exception of Fandom Utilities.
 * Rollback

I wanted to make sure that Deluxe Administrators would be able to quickly revert and delete spam and vandalism, since the QuickTools repository implies that Deluxe Administrators would not be able to revert spam and vandalism as a standalone group without the Rollback right.

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them having the Quicktools permission without the Rollback permission are very small.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, since Bureaucrats had the ability as a standalone group as well at the time it was granted to Deluxe Administrators, and also having the ability prevents abusive Bureaucrats and Administrators from taking advantage of Deluxe Administrators, and preventing them from doing their jobs.
 * Block

Having the ability to block as a standalone group prevents abusive Bureaucrats from taking advantage of Deluxe Administrators by revoking their Administrator rights, even though Deluxe Administrators are able to add their Administrator rights back without difficulty. Since the Deluxe Administrator usergroup is only granted to highly experienced and trusted Administrators, the likelihood of Bureaucrats and Administrators needing to block them are very small. Although Bureaucrats cannot demote Deluxe Administrators by default, having the option to demote them would be granted on request.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, since all the usergroups that currently have the Nuke permission also have the Delete permission.
 * Delete

Furthermore, I checked on to see if users were able to use the Nuke permission without the Delete permission, and it turns out that the Delete permission is required for the Nuke extension to work. Assuming that the Delete permission is required for the Nuke extension to work on Fandom as well, I decided that Deluxe Administrators should have the Delete permission as a standalone group.

The Delete permission would also be required for the fictional Selectivedelete permission to work on Fandom, as the Selectivedelete permission does not grant users access to the ?action=delete page. It only adds additional options, allowing users with the Delete permission to delete a selection of revisions from the page history, moving them to the archive table, as opposed to the usual method of deleting the entire page and then restoring the selective revisions.

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them having the Nuke or Selectivedelete permissions without the Delete permission are very small.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, since all the usergroups that currently have the Editinterfacetrusted permission also have the Undelete permission, with the exception of Fandom Utilities. I wanted to make sure that Deluxe Administrators would be able to undelete MediaWiki messages, since there is no reliable evidence that the Editinterfacetrusted permission would allow them to undelete MediaWiki messages without the Undelete permission.
 * Undelete

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them having the Editinterfacetrusted permission without the Undelete permission are very small.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this after acknowledging that the Deleterevision permission allowed revisions of pages with large histories to be deleted without the Bigdelete permission, something that the Delete permission can't do.
 * Bigdelete

The fictional Selectivedelete permission which only allows users with the Delete permission to delete selective revisions of pages as opposed to deleting and partially undeleting them, obviously wouldn't be able to allow selective revisions of pages with large histories to be deleted. Therefore the Bigdelete permission would be needed in cases where the page histories were too large for the Selectivedelete permission to delete selective revisions from.

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them having the Selectivedelete permission without the Bigdelete permission are very small.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, since all the usergroups that currently have the Editinterfacetrusted permission also have the Deletedhistory and Undelete permissions, with the exception of Fandom Utilities.
 * Deletedhistory

I wanted to make sure that Deluxe Administrators would be able to undelete MediaWiki messages, since there is no reliable evidence that the Editinterfacetrusted permission would allow them to undelete MediaWiki messages without the Undelete permission, and the Deletedhistory permission is required to use the Undelete permission.

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them having the Editinterfacetrusted permission without the Deletedhistory and Undelete permissions are very small.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to be able to delete cascade-protected pages with the Delete permission, regardless if they didn't have Administrator rights.
 * Protect

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them having the Protect permission without being flagged as an Administrator are very small.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to be able to delete protected blog articles with the Delete permission, regardless if they didn't have Administrator rights.
 * Blog-articles-protect

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them having the Blog-articles-protect permission without being flagged as an Administrator are very small.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to be able to delete blog articles with the Delete permission, regardless if they didn't have Administrator rights.
 * Blog-articles-edit

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them having the Blog-articles-edit permission without being flagged as an Administrator are very small.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, since all the usergroups that currently have the Editinterfacetrusted permission also have the Editinterface permission, with the exception of Fandom Utilities. I wanted to make sure that Deluxe Administrators would be able to edit, move, delete, and undelete MediaWiki messages, as it turns out that they were unable to do so without the Editinterface permission.
 * Editinterface

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them having the Editinterfacetrusted permission without the Editinterface permission are very small.

Fandom Staff, Fandom Helpers, and Vanguards have the ability to edit CSS pages on UCP wikis. Administrators, Wiki Managers, Content Team Members, and Content Volunteers were subsequently granted this ability on UCP wikis in April 2020. Volunteer Spam Task Force members were also subsequently granted this ability on UCP wikis in April 2020, prior to the usergroup's retirement.
 * Editsitecss

Spam Obliteration and Prevention members were also granted this ability on UCP wikis, following their introduction in July 2020. Deluxe Administrators were granted this ability in March 2020 so that they would be able to edit CSS pages on UCP wikis without having to wait for Administrators to be granted the ability a month later.

Fandom Staff and Fandom Helpers have the ability to edit JavaScript pages on UCP wikis. Wiki Managers, Content Team Members, Content Volunteers, and Vanguards were subsequently granted this ability on UCP wikis in July 2020. Volunteer Spam Task Force members were also subsequently granted this ability on UCP wikis in July 2020, prior to the usergroup's retirement.
 * Editsitejs

Spam Obliteration and Prevention members were also granted this ability on UCP wikis, following their introduction in July 2020. Administrators were granted the ability to edit JavaScript pages on UCP wikis that have JavaScript enabled in August 2020. Deluxe Administrators were granted this ability in March 2020 so that they would be able to edit JavaScript pages on UCP wikis without having to wait for Administrators to be granted the ability nearly 5 months later.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, since Bureaucrats have the ability as a standalone group as well, and also it prevents Deluxe Administrators from falling victim to autoblocks, regardless if they didn't have Administrator rights.
 * Ipblock-exempt

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of this happening are very small.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, since it would prevent Deluxe Administrators from falling victim to proxy blocks, regardless if they didn't have Administrator rights.
 * Proxyunbannable

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of this happening are very small.

Deluxe Administrators were subsequently granted the ability to bypass automatic blocks of proxies so they wouldn't fall victim to proxy blocks on UCP wikis, since Administrators currently don't have the permission on UCP wikis.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, since Bureaucrats have the ability as a standalone group as well, and also having the ability prevents abusive Bureaucrats and Administrators from taking advantage of Deluxe Administrators, and preventing them from doing their jobs.
 * Unblockself

Having the ability to unblock oneself as a standalone group prevents abusive Bureaucrats from taking advantage of Deluxe Administrators by revoking their Administrator rights and then blocking them, since Deluxe Administrators would otherwise be unable to unblock themselves.

Since the Deluxe Administrator usergroup is only granted to highly experienced and trusted Administrators, the likelihood of Bureaucrats and Administrators needing to block them is very small. Although Bureaucrats cannot demote Deluxe Administrators by default, having the option to demote them would be granted on request.

In addition to the ability to limit actions that can be performed for some groups for a limited time with the Protectsite permission, Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, and Spam Obliteration and Prevention members have the ability to be exempted from sitewide action restrictions across all wikis.
 * Protectsite-exempt

Volunteer Spam Task Force members also had the ability to be exempted from sitewide action restrictions across all wikis, prior to the usergroup's retirement. Administrators were subsequently granted the ability on local wikis in April 2019. The ability existed to allow global groups to edit wikis that had Protectsite enabled, and before Administrators were granted the ability, they were automatically exempted from these restrictions locally anyway.

Deluxe Administrators were granted the ability to be exempted from sitewide action restrictions in November 2018, even if they didn't have Administrator rights, but only on individual wikis. However since the Deluxe Administrator usergroup is only granted to highly experienced and trusted users that currently have Administrator rights, it is largely redundant for Deluxe Administrators to have the Protectsite-exempt permission, since they are almost always flagged as Administrators anyway.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, because even though the ListGroupRights special page implies that Fandom Staff, Wiki Managers, Fandom Helpers, Spam Obliteration and Prevention members, and local Administrators are able to block the emails of users when blocking them, this is at least partially incorrect.
 * Blockemail

None of the five groups that have the ability to block the emails of users when blocking them have been able to use the ability for years. The option to block the emails of users when blocking them was removed at some point in early 2014. From then on, the only way to block the emails of users when blocking them was by blocking them with Quicktools. But even then, the blocking of the target user's emails cannot be done manually. It is always done automatically when using Quicktools to block users.

Since only Volunteer Spam Task Force members had both the abilities to block the emails of users when blocking them, and the ability to use Quicktools, they would technically have been the only standalone group that retained the ability to block the emails of users when blocking them, but only via Quicktools. Fandom Utilities was the only other group with the ability to use Quicktools, but not the ability to block the emails of users when blocking them, or even the ability to block users.

However almost all members of the Fandom Utility usergroup either have Fandom Staff or Fandom Helper rights, both of which have both the ability to block the emails of users, and the ability to block users. So they would still have been able to block the emails of users when blocking them through Quicktools, provided they had Fandom Utility rights. Fandom Helpers were subsequently granted the ability to use Quicktools as a standalone usergroup in July 2016. When Wiki Managers, Content Team Members, and Spam Obliteration and Prevention members were introduced in May and July 2019, and July 2020, respectively, they were also granted the ability to use Quicktools.

Even though Deluxe Administrators were subsequently given the ability to block the emails of users when blocking them, it is pointless even with Quicktools and without Administrator rights. Since the ability to block the emails of users when blocking them no longer does anything. On top of that, sending emails to other users is no longer possible on most wikis, if there are still any wikis that have the ability to send emails to other users enabled.

Administrators and Fandom Helpers previously had this ability until August 2015. However it was removed from both usergroups due to security reasons. From then on, only Fandom Staff had the ability to edit and delete the personal CSS pages belonging to other users. Fandom Helpers subsequently regained the ability to edit and delete the personal CSS pages belonging to other users in August 2020.
 * Editusercss

Having Deluxe Administrator rights reinstates a user's ability to edit and delete the personal CSS pages belonging to other users. However Deluxe Administrators shouldn't use their powers to take advantage of the way other users edit their CSS pages. Deluxe Administrators should only minor changes to the CSS pages of other users such as fixing a broken code, though they are normally expected to ask the owner of the CSS pages before making changes.

The instances where Deluxe Administrators need to edit or delete CSS pages without asking is minimal, such as removing CSS messages that are deliberately intended to attack other users, or spam CSS pages containing offensive language.

Administrators and Fandom Helpers previously had this ability until August 2015. However it was removed from both usergroups due to security reasons. From then on, only Fandom Staff had the ability to edit and delete the personal JavaScript pages belonging to other users. Fandom Helpers subsequently regained the ability to edit and delete the personal JavaScript pages belonging to other users in August 2020.
 * Edituserjs

Having Deluxe Administrator rights reinstates a user's ability to edit and delete the personal JavaScript pages belonging to other users. However Deluxe Administrators shouldn't use their powers to take advantage of the way other users edit their JavaScript pages. Deluxe Administrators should only minor changes to the JavaScript pages of other users such as fixing a broken script that causes a lot of links to show on Special:WantedPages.

Aside from reducing the amount of wanted pages, Deluxe Administrators are normally expected to ask the owner of the JavaScript pages before making changes. The instances where Deluxe Administrators need to edit or delete JavaScript pages without asking is minimal, such as removing JavaScript messages that are deliberately intended to attack other users, or spam JavaScript pages containing offensive language.

Fandom Staff, Fandom Helpers, and Administrators have the ability to edit and delete the personal JavaScript Object Notation pages belonging to other users. However they only have this ability on UCP wikis. It is unknown whether these usergroups will still have this ability by the time all Fandom wikis are migrated to UCP.
 * Edituserjson

Deluxe Administrators were granted this ability so that they would be able to edit and delete other users' personal JavaScript Object Notation pages once all Fandom wikis are migrated to UCP. Since they already have the abilities to edit and delete the personal CSS and JavaScript pages belonging to other users, as well as being able to edit all system messages, which Administrators were able to do until August 2015.

However Deluxe Administrators shouldn't use their powers to take advantage of the way other users edit their JavaScript Object Notation pages. Deluxe Administrators should only minor changes to the JavaScript Object Notation pages of other users such as fixing a broken code, though they are normally expected to ask the owner of the JavaScript Object Notation pages before making changes.

The instances where Deluxe Administrators need to edit or delete JavaScript Object Notation pages without asking is minimal, such as removing JavaScript Object Notation messages that are deliberately intended to attack other users, or spam JavaScript Object Notation pages containing offensive language.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to override the title and username blacklists, regardless if they didn't have Administrator rights.
 * Tboverride

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them falling victim to title and username blacklists are very small.

Deluxe Administrators were subsequently granted the ability to override title and username blacklists so they wouldn't fall victim to them on UCP wikis, since Administrators currently don't have the permission on UCP wikis.

Administrators, Content Moderators, Bots, and Content Volunteers previously had this ability until May 2018. However it was removed from all local usergroups and Content Volunteers, due to the ability becoming more conservative due to abuse. Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, and Spam Obliteration and Prevention members are the only remaining usergroups with the ability to be exempted from rate limits.
 * Noratelimit

Volunteer Spam Task Force members also had the ability to be exempted from rate limits, prior to the usergroup's retirement. When the ability was removed from Administrators, Content Moderators, Bots, and Content Volunteers; Global Bots were granted with the ability to be exempted from rate limits. As of May 2018, there aren't any local usergroups with the ability, excluding a few custom usergroups on certain wikis.

As with all other permissions that have been removed from Administrators since August 2015 that are still in use by some global usergroups, the ability to be exempted from rate limits was subsequently included with the Deluxe Administrator usergroup as of May 2018. Since only highly experienced and trusted Administrators would be entrusted with Deluxe Administrator rights, those users would be entrusted - at least in theory - with being exempted from rate limits.

Even though this ability is already included with the Administrator usergroup, I immediately decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to be able to view the discussions leaderboard, regardless if they didn't have Administrator rights.
 * Leaderboard : view

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them having the Leaderboard:view permission without being flagged as an Administrator are very small.

Deluxe Administrators were granted the ability to view the discussions leaderboard in September 2020, since none of the usergroups with the permission on legacy wikis had the permission on UCP wikis at the time, disregarding the fact that Administrators could view the discussions leaderboard on UCP wikis anyway. And it was only a couple of days before the usergroups with the permission on legacy wikis were granted the permission on UCP wikis.

Fandom Staff, Wiki Managers, Fandom Helpers, Volunteer Spam Task Force and Spam Obliteration and Prevention members, Global Discussion Moderators, Administrators, and Discussion Moderators have the ability to delete article and blog comments.
 * Posts : delete

Deluxe Administrators were granted this ability so that they would be able to delete article and blog comments on UCP wikis, since those features are not part of the MediaWiki software, unlike their counterparts that are still on the legacy platform.

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them having the Posts:delete permission without being flagged as an Administrator are very small.

Global Discussion Moderators, Administrators, and Discussion Moderators have the ability to delete message wall messages and discussion posts. Fandom Staff, Wiki Managers, Fandom Helpers, and Volunteer Spam Task Force and Spam Obliteration and Prevention members were subsequently granted the ability in October 2020.
 * Threads : delete

Deluxe Administrators were granted this ability so that they would be able to delete message wall messages and discussion posts on UCP wikis, since those features are not part of the MediaWiki software, unlike their counterparts that are still on the legacy platform.

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them having the Threads:delete permission without being flagged as an Administrator are very small.

Fandom Staff, Wiki Managers, Fandom Helpers, Volunteer Spam Task Force and Spam Obliteration and Prevention members, Global Discussion Moderators, Administrators, and Discussion Moderators have the ability to delete all posts by a specific user.
 * Posts : deleteall

Deluxe Administrators were granted this ability in October 2020 so that they would be able to delete all posts by a specific user, in addition to the ability to delete article and blog comments on UCP wikis, since those features are not part of the MediaWiki software, unlike their counterparts that are still on the legacy platform.

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them having the Posts:deleteall permission without being flagged as an Administrator are very small.

Administrators, Admin Mentors, Fandom Helpers, and Fandom Staff previously had this ability until sometime between July and November 2015. However it was removed from all usergroups, because the particular part of the Special:Import feature was never enabled on Fandom, unlike the ability to import pages from a file upload which is still active and functional to this day.
 * Import

Despite the ability to import pages from other wikis not working on Fandom, Wiki Managers were subsequently granted the ability in July 2019, as were Content Team Members when the usergroup was introduced in July 2019 on the same day.

Because Wiki Managers and Content Team Members were granted the ability to import pages from other wikis in July 2019, and because Administrators previously had the ability, I subsequently decided that Deluxe Administrators should have the ability, disregarding the fact that it was never enabled on Fandom to start with.

Even though Administrators, Fandom Helpers, and Fandom Staff have the ability to import pages from other wikis on UCP wikis, it had not yet been enabled. Whether it will ever be enabled on the Fandom network remains to be seen.

Administrators, Bureaucrats, and Admin Mentors previously had this ability until sometime in 2015. However it was removed from all usergroups, most likely because the ability doesn't have any relevance to the current code base, since account registration was overhauled.
 * Override-antispoof

As of 2015, certain custom usergroups on certain wikis, such as Assistants, are the only remaining usergroups that have the ability to override spoofing checks when renaming accounts. As such, there are no local usergroups with the permission on any wiki.

Even though Deluxe Administrators have the ability to override spoofing checks when renaming accounts, the ability doesn't have any relevance to the current code base, since account registration was overhauled. So in practice it has largely considered to have outlived its use.

This is probably one of the abilities that many Administrators would want to have the most. Administrators, Admin Mentors, Fandom Helpers, and Fandom Staff previously had the ability to edit, move, and undelete all MediaWiki messages until August 2015. However most of the pages inside the MediaWiki namespace were locked, and only whitelisted messages could be edited, due to security reasons.
 * Editinterfacetrusted

Editinterfacetrusted was added in August 2015 and functions the same way Editinterface did up until then, allowing users with the permission to be able to edit, move, delete, and undelete any messages in the MediaWiki namespace. However only Fandom Utilities were granted the ability to edit, move, delete, and undelete all MediaWiki messages, while Administrators retained the ability to delete all MediaWiki messages with the Deleteinterfacetrusted permission.

Volunteer Spam Task Force members were also granted the ability to edit, move, delete, and undelete all MediaWiki messages, prior to the usergroup's retirement. Fandom Helpers were subsequently granted the ability to edit, move, delete, and undelete all MediaWiki messages in November 2016. When Wiki Managers, Content Team Members, and Spam Obliteration and Prevention members were introduced in May and July 2019, and July 2020, respectively, they were also granted the ability to edit, move, delete, and undelete all MediaWiki messages.

I remember how disappointed and irritated I got when I first heard that Administrators were no longer able to edit, move, delete, and undelete all MediaWiki messages, because I felt that being able to edit, move, and undelete all MediaWiki messages was one of the good things about being an Administrator. And it seemed like Administrators couldn't be trusted to edit, move, and undelete MediaWiki messages in general. I was also disappointed to learn that Volunteer Spam Task Force members could still edit, move, and restore all MediaWiki messages.

Although my disappointment never vanished entirely, it did decrease with the passage of time, and upon hearing that Volunteer Spam Task Force members had a much more limited scope and couldn't edit non-whitelisted messages whenever they felt like it. But Editinterfacetrusted is obviously a permission that Deluxe Administrators should have because the key to Deluxe Administrators is to reinstate all the abilities that Administrators used to have that still exist on Fandom in some form, along with a few other permissions that would enhance the Deluxe Administrator's ability to administrate.

While Deluxe Administrators are able to edit, move, delete, and undelete non-whitelisted messages, they should still keep an open mind as to what MediaWiki messages are whitelisted, and what messages are not whitelisted. So that they can be cautious around editing, moving, and restoring certain non-whitelisted messages to avoid any possibilities of raising security concerns. Deluxe Administrators should also be careful to avoid editing any system messages that change the appearance of the wiki's community header and global footer, since doing that would break the customisation policy.

Fandom Staff, Fandom Helpers, and Administrators have the ability to edit JavaScript Object Notation pages on UCP wikis. It is unknown whether these usergroups will still have this ability by the time all Fandom wikis are migrated to UCP.
 * Editsitejson

Deluxe Administrators were granted this ability so that they would be able to edit JavaScript Object Notation pages once all Fandom wikis are migrated to UCP, regardless of what other usergroups will be able to edit JavaScript Object Notation pages by this time. Since they already have the abilities to edit all system messages, which Administrators were able to do until August 2015.

Fandom Staff have the ability to run the updateSpecialPages maintenance script to refresh the data shown on special pages. Wiki Managers and Content Team Members were subsequently granted the ability to force an update of special pages in July 2019, while Fandom Helpers and Vanguards were granted the ability in August 2019. Administrators do not have this ability on Fandom by default, most likely because it would carry a strain on servers, and it is only intended to be extended to usergroups that seriously need to access it.
 * Schedule-update-special-pages

Unlike Administrators, Deluxe Administrators were subsequently granted the ability to force an update of special pages via the script schedule button on the Special:Statistics page. This is because I've always frowned upon how many special pages only update once per day, and it would be useful for Administrators to be able to manually purge special pages. And since Deluxe Administrators are meant to be a more enhanced version of Administrators, it is obvious why Deluxe Administrators have the ability to force updates of special pages.

But like the other permissions that Deluxe Administrators have that are only extended to global usergroups, Deluxe Administrators shouldn't use the ability to force updates of special pages too frequently. They should only use it in situations where it would be tedious to wait for the special pages to update by themselves, and not use it just for the sake of it.

In addition to the ability to delete and undelete pages, Volunteer Spam Task Force members were able to show and hide the contents of specific revisions, the edit summaries of the revisions, the names of the users/IP addresses that made the edits, or any combination of those three, prior to the usergroup's retirement. Fandom Utilities also have this ability. When Spam Obliteration and Prevention members were introduced in July 2020, they were also granted this ability. Once a revision is hidden, users without the Deletedhistory and Deletedtext permissions cannot view them, and users without the permission cannot view or restore them.
 * Deleterevision

Administrators do not have this ability on Fandom by default, as it is intentionally only used to deal with major legal and TOU concerns. And since Staff want to keep its use limited, it isn't something that they typically grant to communities on request.

I once requested to have the ability on this very wiki, under the impression that the purpose of the tool was to delete and restore individual revisions so that users without the Deletedhistory and Deletedtext permissions couldn't view them once deleted, and users without the Deletedhistory and Undelete permissions couldn't restore them. I was under the impression that it was a combination of Delete and Undelete that only focussed on one revision at a time.

My request was turned down, and it was only a matter of time before I discovered what Deleterevision actually did, and how different it was from what I thought it was and how it was used. Unlike Administrators, Deluxe Administrators have the ability to show and hide the contents of specific revisions, the edit summary of the revisions, the names of the users/IP addresses that made the edits, or any combination of those three.

I decided that Deluxe Administrators should have the Deleterevision permission when I was still under the impression that it was used to delete individual revisions so that users without the Deletedhistory and Deletedtext permissions couldn't view them once deleted, and users without the Deletedhistory and Undelete permissions couldn't restore them. By the time I found out what the ability actually did, it had basically stuck as a notable permission extended to Deluxe Administrators.

Since Deluxe Administrators are meant to be a more enhanced version of Administrators, it is obvious why Deluxe Administrators have the ability to show and hide the contents of specific revisions, the edit summary of the revisions, the names of the users/IP addresses that made the edits, or any combination of those three.

But like the other permissions that Deluxe Administrators have that are only extended to global usergroups, Deluxe Administrators should only use the ability against edits that break the TOU or are too sensitive for users without the Deleterevision permission to stumble across. It shouldn't be used for simple disagreements between users that are acting in good faith.

Deluxe Administrators were subsequently granted an ability to selectively delete revisions from the history of a page, rather than the entire page history. It is basically the same as deleting an entire page history and then restoring the selective revisions.
 * Selectivedelete

This ability doesn't actually exist anywhere on the Fandom network, but I got the idea to create a fictional ability that is exclusive to the Deluxe Administrator usergroup since I knew that such an ability wasn't already extended to Administrators or indeed any usergroup, something that I have frowned upon for years. The reason such an ability doesn't exist on Fandom is likely due to the fact that such an ability would easily create serious attribution issues and Creative Commons licence violations.

The fictional ability to selectively delete revisions from the page history, rather than the entire page history basically fulfills my want for the fictional Deluxe Administrator usergroup to be able to delete selective revisions from the page history. Up until late 2017, I was under the impression that such an equivalent to the ability was already taken by the Deleterevision ability, only that it couldn't focus on more than one revision at a time.

But I eventually discovered that that wasn't the case. And that it was necessary to create a fictional ability that would do what I originally thought Deleterevision did, only that it would be able to focus on any revision that wasn't currently deleted, including the current revision. Basically the opposite of what Undelete does.

Since Deluxe Administrators are meant to be a more enhanced version of Administrators, it is obvious why Deluxe Administrators have the ability to delete selective revisions from the page history, rather than the entire page history. Even though Deluxe Administrators have the Editinterfacetrusted permission and can therefore restore CSS pages, as well as JavaScript pages, messages with the Custom-٭, Editnotice-٭, Gadget-٭, Gadgets-٭, and Tag-٭ prefixes, and non-whitelisted system messages.

Deluxe Administrators should only use Selectivedelete to remove revisions that contain information that is too sensitive for non-administrators to stumble across. It should also be used to remove revisions where a vandal has inserted offensive language, usually language that violates Fandom's terms of use. It shouldn't be used for simple disagreements between users that are acting in good faith.

In addition to the ability to delete pages, Fandom Staff and Fandom Helpers are able to mass delete pages and images created by a specific user. Volunteer Spam Task Force members also had this ability, prior to the usergroup's retirement. Wiki Managers and Content Team Members were subsequently granted the ability in December 2019, and Spam Obliteration and Prevention members were granted this ability, following their introduction in July 2020.
 * Nuke

Administrators do not have this ability, likely because it is only meant to be used to combat spam and vandalism. The ability would be abused too easily and too frequently if Administrators were to have it by default. Although there is a script at the Fandom Developers Wiki that allows Administrators and Content Team Members to use a reverse engineered version of the default extension of the same name.

Unlike Administrators, Deluxe Administrators were subsequently granted the ability to mass delete pages and images by default. So they are able to use both the default extension and the reverse engineered version of the extension. Deluxe Administrators have the ability to mass delete pages and images, because Nuke is generally perceived as a faster option than deleting each specific page and image individually.

Since Deluxe Administrators are meant to be a more enhanced version of Administrators, it is obvious why Deluxe Administrators have more enhanced delete options than Administrators. Therefore it is obvious why Deluxe Administrators have the ability to mass delete pages and images.

But like the other permissions that Deluxe Administrators have that are only extended to global usergroups, Deluxe Administrators shouldn't use Nuke for simple disagreements between users that are acting in good faith. They should only use it to delete obvious spam and vandalism.

None of the usergroups on Fandom have the ability to merge the history of two pages by default, as the feature has never existed on legacy wikis. Despite this, the special page related to the permission exists on all Fandom communities. Administrators and Fandom Staff also have the permission on certain wikis.
 * Mergehistory

Unlike Administrators, Deluxe Administrators were subsequently granted the ability to merge the history of two pages by default. This means that Deluxe Administrators would have the ability to merge the history of two pages even if they don't have Administrator rights, or the wiki doesn't have the Mergehistory permission granted to local Administrators.

Since Deluxe Administrators are meant to be a more enhanced version of Administrators, it is obvious why Deluxe Administrators would be granted the ability to merge the history of pages by default. However they should be careful when merging page histories, as the permission can be easily misused.

In addition to the ability to be exempted from sitewide action restrictions across all wikis, Fandom Staff and Fandom Helpers have the ability to limit actions that can be performed for some groups for a limited time on all wikis. Volunteer Spam Task Force members also had this ability, prior to the usergroup's retirement. Wiki Managers were subsequently granted the ability in December 2019.
 * Protectsite

When Spam Obliteration and Prevention members were introduced in July 2020, they were also granted this ability. Administrators do not have this ability on Fandom by default, because it is generally only enabled on communities that have an extensive history of spam or vandalism.

The ability would be abused too easily and too frequently if Administrators had the ability on wikis by default. There would be too many instances of abusive Administrators preventing non-administrators from creating new accounts, creating new pages, editing pages, renaming pages, or uploading files. Unlike Administrators, Deluxe Administrators were subsequently granted the ability to limit actions that can be performed for some groups for a maximum of 12 hours by default.

Since Deluxe Administrators are meant to be a more enhanced version of Administrators, it is obvious why Deluxe Administrators have more enhanced abilities than Administrators by default. Therefore it is obvious why Deluxe Administrators have the ability to limit actions that can be performed for some groups for a maximum of 12 hours by default.

But like the other permissions that Deluxe Administrators have that are only extended to global usergroups, Deluxe Administrators shouldn't protect wikis for simple disagreements between users that are acting in good faith. They should only use it against excessive spam or vandalism. Deluxe Administrators can have their rights revoked by Staff if they are found to have abused the privilege of protecting wikis that they administrate.

In addition to the ability to delete pages, Volunteer Spam Task Force members were able to quickly block users, and revert and delete spam and vandalism with quick tools, prior to the usergroup's retirement. Fandom Utilities also have access to Quicktools. Fandom Helpers were subsequently granted the ability in July 2016. Wiki Managers, Content Team Members, and Spam Obliteration and Prevention members were also granted the ability, following their respective introductions in May and July 2019, and July 2020. Administrators do not have this ability, likely because it is only meant to be used to combat spam and vandalism.
 * Quicktools

The ability would likely be abused too easily and too frequently if Administrators were to have it by default. Although there are two scripts of the same name at the Fandom Developers Wiki that allow Administrators to do the things that the Quicktools permission can do, as well as various other things that the normal extension doesn't do, such as mass blocking users instead of just blocking them individually.

Unlike Administrators, Deluxe Administrators were subsequently granted the ability to quickly block users, and revert and delete spam and vandalism with quick tools by default. So they are able to use both the default extension and the two scripts that cover all the abilities that the default extension does, and more.

Deluxe Administrators have the ability to quickly block users, and revert and delete spam and vandalism, because Quicktools is generally perceived as a faster option than blocking users, and reverting and deleting each specific page and image individually.

Since Deluxe Administrators are meant to be a more enhanced version of Administrators, it is obvious why Deluxe Administrators have more enhanced delete and block options than Administrators. Therefore it is obvious why Deluxe Administrators have the ability to quickly block users, and revert and delete spam and vandalism.

But like the other permissions that Deluxe Administrators have that are only extended to global usergroups, Deluxe Administrators shouldn't use Quicktools for simple disagreements between users that are acting in good faith. They should only use it to block obvious vandals, and quickly revert and delete obvious spam and vandalism.

In addition to the ability to modify abuse filters on wikis that have abuse filters enabled, Fandom Staff, Wiki Managers, and Content Team Members have the ability to bypass all abuse filters on all wikis that have abuse filters enabled. Fandom Helpers were subsequently granted the ability to bypass all abuse filters on all wikis in August 2020.
 * Abusefilter-bypass

Administrators do not have this ability, likely because it would take away the benefit of making Administrators think twice about the rules they're implementing. Unlike Administrators, Deluxe Administrators were subsequently granted the ability to bypass all abuse filters on individual wikis. Since Deluxe Administrators are meant to be a more enhanced version of Administrators, it is obvious why Deluxe Administrators have the ability to bypass all abuse filters on individual wikis.

Even though Deluxe Administrators are able to bypass all abuse filters on individual wikis, they are still expected to think twice about the rules they're implementing. Deluxe Administrators are able to bypass all abuse filters on individual wikis so they don't have to worry about modifying the abuse filters to prevent themselves from falling victim to them. They can have their rights revoked by Staff if they are found to have abused the privilege of bypassing abuse filters.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to access Semantic MediaWiki administration tasks on wikis with Semantic MediaWiki enabled, regardless if they didn't have Administrator rights.
 * Smw-admin

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them not being able to access Semantic MediaWiki administration tasks are very small.

Deluxe Administrators were subsequently granted the ability so they would be able to access Semantic MediaWiki administration tasks on UCP wikis with Semantic MediaWiki enabled, since Administrators currently don't have the permission on UCP wikis.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have this ability even as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to edit access to maintain allowed regular expressions and patterns on wikis with Semantic MediaWiki enabled, regardless if they didn't have Administrator rights.
 * Smw-patternedit

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them not being able to edit access to maintain allowed regular expressions and patterns are very small.

Deluxe Administrators were subsequently granted the ability so they would be able to edit access to maintain allowed regular expressions and patterns on UCP wikis with Semantic MediaWiki enabled, since Administrators currently don't have the permission on UCP wikis.

None of the usergroups on Fandom wikis that use MediaWiki 1.19.24 have the ability to edit semi-protected pages, as the permission has never existed on that version of MediaWiki. However the permission's purpose is covered by the Autoconfirmed permission on legacy wikis which is extended to Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, Spam Obliteration and Prevention members, Content Volunteers, Bots, Administrators, Assistants, and Autoconfirmed Users.
 * Editsemiprotected

Volunteer Spam Task Force members also had the Autoconfirmed permission, prior to the usergroup's retirement. On UCP wikis, the Autoconfirmed permission no longer grants users the ability to edit semi-protected pages, and Fandom Staff, Wiki Managers, Fandom Helpers, Spam Obliteration and Prevention members, Vanguards, Bots, Administrators, Content Moderators, and Autoconfirmed Users have the Editsemiprotected permission on UCP wikis. Volunteer Spam Task Force members also had the Editsemiprotected permission on UCP wikis, prior to the usergroup's retirement. Content Team Members were subsequently granted the ability to edit semi-protected pages on UCP wikis in August 2020.

Deluxe Administrators were subsequently granted the ability to edit semi-protected pages since it was decided that they would be granted all the administrative abilities that weren't granted to any of the usergroups on legacy and/or UCP wikis. It also ensures that they can edit semi-protected pages without being part of any other usergroup. However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, and since they almost always have Autoconfirmed status, the chances of them having the Editsemiprotected permission without the Autoconfirmed permission are very small.

None of the usergroups on Fandom wikis that use MediaWiki 1.19.24 have the ability to edit protected pages without cascading protection by default. However the permission does exist on the legacy platform, according to the system messages referring to usergroup rights. The reason none of the usergroups on legacy wikis have this permission by default is most likely because its purpose is covered by the Protect permission which is extended to Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, Spam Obliteration and Prevention members, Content Volunteers, Vanguards, Administrators, Assistants, and Content Moderators.
 * Editprotected

Volunteer Spam Task Force members also had the Protect permission, prior to the usergroup's retirement. On UCP wikis, the Protect permission no longer grants users the ability to edit fully protected pages. Fandom Staff, Wiki Managers, Fandom Helpers, Spam Obliteration and Prevention members, Vanguards, Administrators, and Content Moderators have the Editprotected permission on UCP wikis. Volunteer Spam Task Force members also had the Editprotected permission on UCP wikis, prior to the usergroup's retirement. Content Team Members were subsequently granted the ability to edit protected pages without cascading protection on UCP wikis in August 2020.

Deluxe Administrators were subsequently granted the ability to edit protected pages without cascading protection since it was decided that they would be granted all the administrative abilities that weren't granted to any of the usergroups on legacy and/or UCP wikis. It also ensures that they can edit protected pages without being part of any other usergroup. However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them having the Editprotected permission without the Protect permission are very small.

None of the usergroups on Fandom wikis that use MediaWiki 1.19.24 have the ability to view recent changes patrol marks by default. However the permission does exist on the legacy platform, according to the system messages referring to usergroup rights. The reason none of the usergroups on legacy wikis have this permission by default is most likely because its purpose is covered by the Patrol permission which is extended to Fandom Staff, Wiki Managers, Fandom Helpers, Administrators, Assistants, and Content Moderators.
 * Patrolmarks

Deluxe Administrators were subsequently granted the ability to view recent changes patrol marks since it was decided that they would be granted all the administrative abilities that weren't granted to any of the usergroups on legacy and/or UCP wikis. It ensures that they can view recent changes patrol marks without being part of any other usergroup.

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them having the Patrolmarks permission without the Patrol permission are very small.

None of the usergroups on Fandom wikis that use MediaWiki 1.19.24 have the ability to override the username blacklist by default. However the permission does exist on the legacy platform, according to the system messages referring to usergroup rights.
 * Tboverride-account

Deluxe Administrators were subsequently granted the ability to override the username blacklist since it was decided that they would be granted all the administrative abilities that weren't granted to any of the usergroups on legacy and/or UCP wikis.

One could argue that Deluxe Administrators having this permission is redundant, as on UCP wikis, the purpose of the Tboverride-account permission is also covered by the Tboverride permission which has also been granted to Deluxe Administrators.

None of the usergroups on Fandom wikis that use MediaWiki 1.19.24 have the ability to rename categories, as the feature has never existed on that version of MediaWiki. However such a feature does exist on certain newer versions of MediaWiki, including 1.33.2 which certain Fandom wikis already use.
 * Move-categorypages

Administrators, Fandom Helpers, Fandom Staff, and Registered Users have this ability on UCP wikis but not legacy wikis. It is unknown whether these usergroups will still have this ability by the time all Fandom wikis are migrated to UCP.

There is a script at the Fandom Developers Wiki that allows users to automatically replace categories and fix category links on other pages. So using the script is actually faster and easier than it would be to use the category rename feature. Deluxe Administrators were granted the ability to rename categories in December 2018, disregarding the fact that the ability has not been added to UCP wikis.

Since Deluxe Administrators are meant to be a more enhanced version of Administrators, it is obvious why Deluxe Administrators were given the ability to move category pages. However they should be careful when renaming categories, to make sure that any pages linking to the old name of the category are updated.


 * Gadgets-definition-edit


 * Gadgets-edit

None of the usergroups on Fandom wikis that use MediaWiki 1.19.24 have the ability to create and deactivate tags, as the feature has never existed on that version of MediaWiki. However such a feature does exist on certain newer versions of MediaWiki, including 1.33.2 which certain Fandom wikis already use. Administrators, Fandom Helpers, and Fandom Staff have this ability on UCP wikis but not legacy wikis. It is unknown whether these usergroups will still have this ability by the time all Fandom wikis are migrated to UCP.
 * Managechangetags

Deluxe Administrators were granted the ability to create and deactivate tags in case Administrators ever lost the ability. Since Deluxe Administrators are meant to be a more enhanced version of Administrators, it is obvious why Deluxe Administrators should keep any permissions that are removed from Administrators, unless the permissions are removed from the Fandom network altogether.

None of the usergroups on Fandom wikis that use MediaWiki 1.19.24 have the ability to delete tags from the database, as the feature has never existed on that version of MediaWiki. However such a feature does exist on certain newer versions of MediaWiki, including 1.33.2 which certain Fandom wikis already use. Administrators, Fandom Helpers, and Fandom Staff have this ability on UCP wikis but not legacy wikis. It is unknown whether these usergroups will still have this ability by the time all Fandom wikis are migrated to UCP.
 * Deletechangetags

Deluxe Administrators were granted the ability to delete tags from the database in case Administrators ever lost the ability. Since Deluxe Administrators are meant to be a more enhanced version of Administrators, it is obvious why Deluxe Administrators should keep any permissions that are removed from Administrators, unless the permissions are removed from the Fandom network altogether.

None of the usergroups on Fandom wikis that use MediaWiki 1.19.24 have the ability to change the content models of pages, as the feature has never existed on that version of MediaWiki. However such a feature does exist on certain newer versions of MediaWiki, including 1.33.2 which certain Fandom wikis already use. Administrators have this ability on UCP wikis but not legacy wikis.
 * Editcontentmodel

Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, Spam Obliteration and Prevention members, Content Volunteers, Vanguards, and Content Moderators were subsequently granted this ability on UCP wikis in July 2020. Volunteer Spam Task Force members were also subsequently granted this ability on UCP wikis in July 2020, prior to the usergroup's retirement.

Deluxe Administrators were granted the ability to change the content models of pages in case Administrators and Content Moderators ever lost the ability. Since Deluxe Administrators are meant to be a more enhanced version of Administrators, it is obvious why Deluxe Administrators should keep any permissions that are removed from Administrators, unless the permissions are removed from the Fandom network altogether.

None of the usergroups on Fandom wikis that use MediaWiki 1.19.24 have the ability to view information about current transcode activities, as the feature has never existed on that version of MediaWiki. However such a feature does exist on certain newer versions of MediaWiki, including 1.33.2 which certain Fandom wikis already use. Administrators have this ability on UCP wikis but not legacy wikis.
 * Transcode-status

Deluxe Administrators were granted the ability to view information about current transcode activities in case Administrators ever lost the ability. Since Deluxe Administrators are meant to be a more enhanced version of Administrators, it is obvious why Deluxe Administrators should keep any permissions that are removed from Administrators, unless the permissions are removed from the Fandom network altogether.

None of the usergroups on Fandom wikis that use MediaWiki 1.19.24 have the ability to disable comments on article pages and blog articles, as the feature has never existed on Fandom legacy wikis. However such a feature does exist on Fandom UCP wikis. Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, Spam Obliteration and Prevention members, Administrators, and Discussion Moderators have this ability on UCP wikis but not legacy wikis.
 * Disablecomments

Deluxe Administrators were granted the ability to disable comments on article pages and blog articles since it was decided that they would receive various permissions extended to Administrators on UCP wikis that aren't extended to them on legacy wikis, until all wikis have migrated to UCP. Furthermore, I felt that they would benefit from having this permission as a standalone group.

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them not having the Disablecomments permission are very small.

None of the usergroups on Fandom wikis that use MediaWiki 1.19.24 have the ability to request database dumps on demand, via Special:Statistics, as the Dumpsondemandrequest permission has never existed on Fandom legacy wikis. However the permission does exist on Fandom legacy wikis as Dumpsondemand which is extended to Fandom Staff, Wiki Managers, Fandom Helpers, and Administrators on legacy wikis.
 * Dumpsondemandrequest

On UCP wikis, both the Dumpsondemand and Dumpsondemandrequest permissions are extended to Fandom Staff, Fandom Helpers, and Administrators. This creates the impression that the Dumpsondemand and Dumpsondemandrequest permissions combined function the same way on UCP wikis that the Dumpsondemand permission alone does on legacy wikis.

Deluxe Administrators were granted the ability to request database dumps on demand since it was decided that they would receive various permissions extended to Administrators on UCP wikis that aren't extended to them on legacy wikis, until all wikis have migrated to UCP. Furthermore, I felt that they would benefit from having this permission as a standalone group.

However since the Deluxe Administrator usergroup isn't granted to any user that did not currently have Administrator rights, and since Deluxe Administrators don't normally revoke their Administrator rights without revoking their Deluxe Administrator rights, the chances of them not having the Dumpsondemandrequest permission are very small.

None of the usergroups on Fandom wikis that use MediaWiki 1.19.24 have the ability to see the reported content button on the bottom toolbar, as the feature has never existed on Fandom legacy wikis. However such a feature does exist on Fandom UCP wikis. Fandom Staff, Fandom Helpers, Spam Obliteration and Prevention members, Global Discussion Moderators, Administrators, and Discussion Moderators have this ability on UCP wikis but not legacy wikis.
 * Reportedcontent

Deluxe Administrators were granted the ability to see the reported content button on the bottom toolbar so that they'd be able to respond more swiftly to reported article and blog comments on UCP wikis, and discussion posts as a standalone group. Since Deluxe Administrators already have the abilities to delete article and blog comments on UCP wikis, and discussion posts, it made sense for them to be granted the ability to see the reported content button on the bottom toolbar as a standalone group as well.

None of the usergroups on Fandom wikis have the ability to create and edit widgets in the Widget namespace, as the feature has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on UCP wikis. Deluxe Administrators were granted the ability to create and edit widgets in the Widget namespace, in case the extension is ever added to UCP wikis.
 * Editwidgets

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom UCP wikis. The ability to create and edit widgets in the Widget namespace is extended to Administrators on Gamepedia wikis, which is why I thought it made sense for it to be immediately granted to Deluxe Administrators, should the extension ever be added to Fandom wikis.

None of the usergroups on Fandom wikis have the ability to view the spam blacklist log, as the feature has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on UCP wikis. Deluxe Administrators were granted the ability to view the spam blacklist log, in case the extension is ever added to UCP wikis.
 * Spamblacklistlog

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom UCP wikis. The ability to view the spam blacklist log is extended to Registered Users on Gamepedia wikis, which is why I thought it made sense for it to be immediately granted to Deluxe Administrators, should the extension ever be added to Fandom wikis.

None of the usergroups on Fandom wikis have the ability to view the title blacklist log, as the feature has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on UCP wikis. Deluxe Administrators were granted the ability to view the title blacklist log, in case the extension is ever added to UCP wikis.
 * Titleblacklistlog

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom UCP wikis. The ability to view the title blacklist log is extended to Administrators on Gamepedia wikis, which is why I thought it made sense for it to be immediately granted to Deluxe Administrators, should the extension ever be added to Fandom wikis.

None of the usergroups on Fandom wikis have the ability to delete cargo tables, as the feature has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on UCP wikis. Deluxe Administrators were granted the ability to delete cargo tables, in case the extension is ever added to UCP wikis.
 * Deletecargodata

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom UCP wikis. The ability to delete cargo tables is extended to Administrators on Gamepedia wikis, which is why I thought it made sense for it to be immediately granted to Deluxe Administrators, should the extension ever be added to Fandom wikis.

None of the usergroups on Fandom wikis have the ability to recreate data contained in cargo tables, as the feature has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on UCP wikis. Deluxe Administrators were granted the ability to recreate data contained in cargo tables, in case the extension is ever added to UCP wikis.
 * Recreatecargodata

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom UCP wikis. The ability to recreate data contained in cargo tables is extended to Administrators on Gamepedia wikis, which is why I thought it made sense for it to be immediately granted to Deluxe Administrators, should the extension ever be added to Fandom wikis.

None of the usergroups on Fandom wikis have the ability to run arbitrary cargo queries, as the feature has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on UCP wikis. Deluxe Administrators were granted the ability to run arbitrary cargo queries, in case the extension is ever added to UCP wikis.
 * Runcargoqueries

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom UCP wikis. The ability to run arbitrary cargo queries is extended to Administrators and Registered Users on Gamepedia wikis, which is why I thought it made sense for it to be immediately granted to Deluxe Administrators, should the extension ever be added to Fandom wikis.

None of the usergroups on Fandom wikis have the ability to mass delete pages using the DynamicPageList, as the feature has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on UCP wikis. Deluxe Administrators were granted the ability to mass delete pages using the DynamicPageList, in case the extension is ever added to UCP wikis.
 * Dpl_param_delete_rules

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom UCP wikis. The ability to mass delete pages using the DynamicPageList is extended to Administrators on Gamepedia wikis, which is why I thought it made sense for it to be immediately granted to Deluxe Administrators, should the extension ever be added to Fandom wikis.

None of the usergroups on Fandom wikis have the ability to mass update pages using the DynamicPageList, as the feature has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on UCP wikis. Deluxe Administrators were granted the ability to mass update pages using the DynamicPageList, in case the extension is ever added to UCP wikis.
 * Dpl_param_update_rules

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom UCP wikis. The ability to mass update pages using the DynamicPageList is extended to Administrators on Gamepedia wikis, which is why I thought it made sense for it to be immediately granted to Deluxe Administrators, should the extension ever be added to Fandom wikis.

None of the usergroups on Fandom wikis have the ability to edit spritesheets, sprites, slices, assign names, and delete, as the feature has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on UCP wikis. Deluxe Administrators were granted the ability to edit sprites, in case the extension is ever added to UCP wikis.
 * Edit_sprites

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom UCP wikis. The ability to edit sprites is extended to Autoconfirmed Users on Gamepedia wikis, which is why I thought it made sense for it to be immediately granted to Deluxe Administrators, should the extension ever be added to Fandom wikis.

None of the usergroups on Fandom wikis have the ability to revert spritesheet changes from the change log, as the feature has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on UCP wikis. Deluxe Administrators were granted the ability to revert spritesheet changes from the change log, in case the extension is ever added to UCP wikis.
 * Spritesheet_rollback

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom UCP wikis. The ability to revert spritesheet changes from the change log is extended to Administrators on Gamepedia wikis, which is why I thought it made sense for it to be immediately granted to Deluxe Administrators, should the extension ever be added to Fandom wikis.

None of the usergroups on Fandom wikis have the ability to edit multiple pages using a spreadsheet, as the feature has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on UCP wikis. Deluxe Administrators were granted the ability to edit multiple pages using a spreadsheet, in case the extension is ever added to UCP wikis.
 * Multipageedit

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom UCP wikis. The ability to edit multiple pages using a spreadsheet is extended to Registered Users on Gamepedia wikis, which is why I thought it made sense for it to be immediately granted to Deluxe Administrators, should the extension ever be added to Fandom wikis.

None of the usergroups on Fandom wikis have the ability to embed PDFs into pages, as the feature has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on UCP wikis. Deluxe Administrators were granted the ability to embed PDFs into pages, in case the extension is ever added to UCP wikis.
 * Embed_pdf

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom UCP wikis. The ability to embed PDFs into pages is extended to Administrators on Gamepedia wikis, which is why I thought it made sense for it to be immediately granted to Deluxe Administrators, should the extension ever be added to Fandom wikis.

None of the usergroups on Fandom wikis have the ability to access the font manager, as the feature has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on UCP wikis. Deluxe Administrators were granted the ability to manage custom fonts, in case the extension is ever added to UCP wikis.
 * Font_manager

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom UCP wikis. The ability to manage custom fonts is extended to Administrators on Gamepedia wikis, which is why I thought it made sense for it to be immediately granted to Deluxe Administrators, should the extension ever be added to Fandom wikis.

None of the usergroups on Fandom wikis have the ability to upload fonts using the font manager, as the feature has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on UCP wikis. Deluxe Administrators were granted the ability to upload custom fonts, in case the extension is ever added to UCP wikis.
 * Font_upload

Also the extension is referenced on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom UCP wikis. The ability to upload custom fonts related to the ability to manage custom fonts, which is why I thought it made sense for it to be immediately granted to Deluxe Administrators, should the extension ever be added to Fandom wikis.

None of the usergroups on Fandom wikis have the ability to batch upload more files at once with the Upload Wizard, as the feature has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on UCP wikis. Deluxe Administrators were granted the ability to batch upload more files at once, in case the extension is ever added to UCP wikis.
 * Mass-upload

Also system messages related to the extension do appear on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom UCP wikis. The ability to batch upload more files at once is generally extended to Administrators on sites where it is enabled, which is why I thought it made sense for it to be immediately granted to Deluxe Administrators, should the extension ever be added to Fandom wikis.

None of the usergroups on Fandom wikis have the ability to delete batches of pages, as the feature has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on UCP wikis. Deluxe Administrators were granted the ability to batch delete pages, in case the extension is ever added to UCP wikis.
 * Deletebatch

Also system messages related to the extension do appear on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom UCP wikis. The ability to batch delete pages is generally extended to Administrators and/or Bureaucrats on sites where it is enabled, which is why I thought it made sense for it to be immediately granted to Deluxe Administrators, should the extension ever be added to Fandom wikis.

Groups that Deluxe Administrators are able to add and remove from other accounts
Deluxe Administrators were subsequently granted the ability to add and remove Assistant rights from other users, after it was decided that they should be able to grant and revoke any local usergroup permissions below Administrator.
 * Assistants

Deluxe Administrators were subsequently granted the ability to add and remove Content Moderator rights from other users, after it was decided that they should be able to grant and revoke any local usergroup permissions below Administrator.
 * Content Moderators

Deluxe Administrators were subsequently granted the ability to add and remove Rollback rights from other users, after it was decided that they should be able to grant and revoke any local usergroup permissions below Administrator.
 * Rollbackers

Groups that Deluxe Administrators are able to add and remove from their own account
Deluxe Administrators are able to add Administrator rights to their own account, should they have their Administrator rights revoked by an abusive Bureaucrat. Deluxe Administrators that abuse their rights cannot be demoted by Bureaucrats by default, though communities would be asked whether they wanted Bureaucrats to be able to demote Deluxe Administrators before granting the rights to the users that were trusted to have Deluxe Administrator rights.
 * Administrators

Deluxe Administrators were subsequently able to remove Administrator rights from their own account, though they could already do this using their Administrator rights. The reason why Deluxe Administrators were granted the ability to remove Administrator rights from their own account is because Fandom Staff usually try not to have usergroups that can add specific rights to their own account without removing those specific rights from their own account as well. There have been issues in the past where users couldn't remove themselves from a specific usergroup.


 * Bots

Groups that Deluxe Administrators are able to remove from their own account

 * Bots

Deluxe Administrators are able to remove their Deluxe Administrator rights from their own account, though they need to be careful when doing this, as there aren't any local usergroups that are able to reinstate their Deluxe Administrator rights.
 * Deluxe Administrators

What should Deluxe Administrators do?
As with regular Administrators, Deluxe Administrators are responsible for maintaining the wiki. In addition to the abilities that come with the Administrator rights that they already have, Deluxe Administrators are able to make minor tweaks to other users' JavaScript pages to fix any broken JavaScript that is causing errors such as unwanted pages on Special:WantedPages.

They are able to make minor fixes to other users' CSS pages where the CSS is obviously broken and how to fix it. Though they are normally expected to contact the owner of the pages before editing them. They are able to delete any CSS or JavaScript pages created by spammers and vandals that contain harmful JavaScript code, or any pages containing only spam or hate messages.

Deluxe Administrators are able to mass delete pages created by spammers and vandals, as well as quickly block users, and revert and delete spam and vandalism. They are able to edit all MediaWiki pages including those that are not accessible to regular administrators, allowing them to customise changes to the wiki's appearance and interface for users.

Due to the lack of restriction of MediaWiki editing, they need to be careful to avoid making any changes that could potentially create security issues or break the customisation policy. Deluxe Administrators are also able to show and hide the contents of specific revisions, the edit summaries of the revisions, the names of the users/IP addresses that made the edits, or any combination of those three.

They are also able to delete selective bad faith revisions of pages to delete, rather than the entire page history and restoring the good revisions. They are able to rename categories, although they should be careful to make sure that the links pointing towards the old category title and any pages that are still categorised under the old category title are updated. Deluxe Administrators are also able to merge the page histories of two pages.

What should Deluxe Administrators not do?
Deluxe Administrators should not use their deluxe administrator powers to settle editing disputes; for example, hide the contents of specific revisions and keep the revisions that he or she prefers in an editing dispute that isn't vandalism. Deluxe Administrator powers should be used to help keep the wiki clear of TOU breaking information and potentially harmful code, but not for simple disagreements between users acting in good faith.

Deluxe Administrators shouldn't selectively delete revisions of pages made by other users that weren't made in bad faith, in order to keep his or her preferred revisions at the top of the page history. They shouldn't make changes to non-whitelisted MediaWiki messages without consent either from the other Administrators or from the general community.

Deluxe Administrators also shouldn't restore non-whitelisted messages that have been voted for deletion via community consensus. They shouldn't make questionable changes to the wiki's interface that may cause security issues or customisation policy violations, deliberate or otherwise.

Deluxe Administrators shouldn't delete the CSS or JavaScript pages of other users that don't contain any malicious code or ones that don't contain spam or hate messages. They also shouldn't make changes to other users' CSS or JavaScript pages if the changes aren't constructive and/or minor such as fixing a broken code.

Deluxe Administrators shouldn't mass delete pages that weren't made in bad faith. Nor should they quickly revert or delete anything that isn't spam or vandalism. Deluxe Administrators shouldn't be careless and rename categories without checking to make sure that the links pointing towards the old category title and any pages that are still categorised under the old category title have been updated.

On wikis with the Abuse Filter extension enabled, Deluxe Administrators shouldn't use the advantage of being able to bypass abuse filters to deliberately perform actions that have been blocked by the abuse filter. On wikis with Achievements enabled, Deluxe Administrators shouldn't create and edit badges that can only be earned by editing pages that only specific usergroups can edit.

Deluxe Administrators shouldn't merge the histories of two obviously unrelated pages. Deluxe Administrators that abuse their powers by deliberately doing any of the things that they aren't supposed to do will have their deluxe administrator status revoked by Staff.

Ideally a deluxe administrator shouldn't be considered "in charge". Nor should they be thought of as outranking regular administrators. The ideal deluxe administrator is just someone who can be trusted to have additional abilities and to use them for the benefit of the wiki community in ways that can't be done without having deluxe administrator rights.