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 many 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 it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to bypass CAPTCHAs, regardless if they didn't have Administrator rights. 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 Skipcaptcha permission without being flagged as an Administrator are very small.
 * Skipcaptcha

Deluxe Administrators were granted the ability to bypass CAPTCHAs in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to bypass IP-based rate limits, regardless if they didn't have Administrator rights. 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 Autoconfirmed permission without being flagged as an Administrator are very small.
 * Autoconfirmed

Deluxe Administrators were granted the ability to bypass IP-based rate limits in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, Spam Obliteration and Prevention members, Vanguards, Bots, Administrators, Content Moderators, and Autoconfirmed Users have the ability to edit semi-protected pages. Assistants were subsequently granted the ability to edit semi-protected pages in October 2020. Content Volunteers previously had the ability to edit semi-protected pages via the Autoconfirmed permission, prior to this wiki's migration to Fandom 's Unified Community Platform in October 2020.
 * Editsemiprotected

Deluxe Administrators were subsequently granted the ability to edit semi-protected pages in August 2020 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.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to reset failed or transcoded videos so they are inserted into the job queue again, regardless if they didn't have Administrator rights. 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 Transcode-reset permission without being flagged as an Administrator are very small.
 * Transcode-reset

Deluxe Administrators were granted the ability to reset transcodes in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to have their own edits automatically marked as patrolled, regardless if they didn't have Administrator rights. 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 Autopatrol permission without being flagged as an Administrator are very small.
 * Autopatrol

Deluxe Administrators were granted the ability to autopatrol their own edits in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it 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.
 * 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 it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to access the administrators' dashboard, regardless if they didn't have Administrator rights. 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 Admindashboard permission without being flagged as an Administrator are very small.
 * Admindashboard

Deluxe Administrators were granted the ability to access the administrators' dashboard in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, Spam Obliteration and Prevention members, Administrators, and Discussion Moderators have the ability to disable comments on article pages and blog articles. Assistants were subsequently granted the ability in October 2020.
 * Disablecomments

Deluxe Administrators were granted the ability to disable comments on article pages and blog articles in September 2020, since it was decided that they would receive various permissions extended to Administrators on UCP wikis that weren't extended to them on legacy wikis, until all wikis were 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.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to view deleted forums in discussions, regardless if they didn't have Administrator rights.
 * Forums : viewhidden

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 Forums:viewhidden permission without being flagged as an Administrator are very small.

Deluxe Administrators were granted the ability to view deleted forums in November 2020, since the ability is not part of the MediaWiki software, and therefore Deluxe Administrators would not be able to view deleted forums with the Deletedtext permission which was granted to them on the same day.

Even though this ability is already included with the Administrator usergroup, I immediately decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators 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.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to use moderator tools in Discussions, regardless if they didn't have Administrator rights. 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 ModeratorTools:use permission without being flagged as an Administrator are very small.
 * ModeratorTools : use

Deluxe Administrators were granted the ability to use moderator tools in Discussions in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

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

Volunteer Spam Task Force members also had the ability to delete and undelete article and blog comments, prior to the usergroup's retirement. Deluxe Administrators were granted the ability in July 2020, so they could delete and undelete article and blog comments, since those features are not part of the MediaWiki software, unlike their counterparts that were 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.

Fandom Staff, Wiki Managers, Fandom Helpers, 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

Volunteer Spam Task Force members also had the ability to delete all posts by a specific user, prior to the usergroup's retirement. Deluxe Administrators were granted the ability in October 2020, so they could delete all posts by a specific user, in addition to the ability to delete and undelete article and blog comments, since those features are not part of the MediaWiki software, unlike their counterparts that were 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.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to lock and unlock article and blog comments, regardless if they didn't have Administrator rights. 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 Post:lock permission without being flagged as an Administrator are very small.
 * Posts : lock

Deluxe Administrators were granted the ability to lock and unlock article and blog comments in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to edit the article and blog comments of other users, as well as edit article and blog comments that were posted more than a day ago, regardless if they didn't have Administrator rights. 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:superedit permission without being flagged as an Administrator are very small.
 * Posts : superedit

Deluxe Administrators were granted the ability to edit the article and blog comments of other users, as well as edit comments that were posted more than a day ago in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to approve reported article and blog comments, message wall messages and discussion posts that were deemed unworthy of deletion, regardless if they didn't have Administrator rights. 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:validate permission without being flagged as an Administrator are very small.
 * Posts : validate

Deluxe Administrators were granted the ability to approve reported article and blog comments, message wall messages and discussion posts that were deemed unworthy of deletion in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to view deleted article and blog comments, regardless if they didn't have Administrator rights.
 * Posts : viewhidden

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:viewhidden permission without being flagged as an Administrator are very small.

Deluxe Administrators were granted the ability to view deleted article and blog comments in November 2020, since those features are not part of the MediaWiki software, unlike their counterparts that were still on the legacy platform. Therefore Deluxe Administrators would not be able to view deleted article and blog comments with the Deletedtext permission which was granted to them on the same day.

Fandom Staff, Fandom Helpers, Spam Obliteration and Prevention members, Global Discussion Moderators, Administrators, and Discussion Moderators have the ability to see the reported content button on the bottom toolbar.
 * Reportedcontent

Deluxe Administrators were granted the ability to see the reported content button on the bottom toolbar in September 2020, so they'd be able to respond more swiftly to reported article and blog comments, and discussion posts as a standalone group. Since Deluxe Administrators already have the abilities to delete and undelete article and blog comments, 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.

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

Volunteer Spam Task Force members were also subsequently granted the ability in October 2020, prior to their retirement. Deluxe Administrators were granted the ability in September 2020, so they could delete and undelete message wall messages and discussion posts, since those features are not part of the MediaWiki software, unlike their counterparts that were 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.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to lock and unlock message wall messages and discussion posts, regardless if they didn't have Administrator rights. 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:lock permission without being flagged as an Administrator are very small.
 * Threads : lock

Deluxe Administrators were granted the ability to lock and unlock message wall messages and discussion posts in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to move message wall messages and discussion posts, regardless if they didn't have Administrator rights. 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:move permission without being flagged as an Administrator are very small.
 * Threads : move

Deluxe Administrators were granted the ability to move message wall messages and discussion posts in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to edit the message wall messages and discussion posts of other users, as well as edit message wall messages and discussion posts that were posted more than a day ago, regardless if they didn't have Administrator rights. 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:superedit permission without being flagged as an Administrator are very small.
 * Threads : superedit

Deluxe Administrators were granted the ability to edit the message wall messages and discussion posts of other users, as well as edit message wall messages and discussion posts that were posted more than a day ago in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to view deleted message wall messages, regardless if they didn't have Administrator rights.
 * Threads : viewhidden

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:viewhidden permission without being flagged as an Administrator are very small.

Deluxe Administrators were granted the ability to view deleted message wall messages in November 2020, since the features is not part of the MediaWiki software, unlike their counterpart that was still on the legacy platform. Therefore Deluxe Administrators would not be able to view deleted message wall messages with the Deletedtext permission which was granted to them on the same day.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it 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 it 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.
 * 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 it as a standalone group. I was inspired to do this, since all the usergroups that currently have the Deleterevision permission also have the Deletedtext permission. Furthermore I eventually acknowledged that the Deleterevision permission would not allow Deluxe Administrators to view the text of hidden revisions without the Deletedtext permission.
 * Deletedtext

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 Deleterevision permission without the Deletedtext permission are very small.

Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, Spam Obliteration and Prevention members, Content Volunteers, Vanguards, Administrators, and Content Moderators have the ability to change the content models of pages. Assistants were subsequently granted the ability in October 2020.
 * Editcontentmodel

Deluxe Administrators were granted the ability to change the content models of pages in August 2020, 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.

Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, Spam Obliteration and Prevention members, Vanguards, Administrators, and Content Moderators were subsequently granted the ability to edit protected pages without cascading protection, following this wiki's migration to Fandom 's Unified Community Platform. Assistants were subsequently granted the ability to edit protected pages without cascading protection in October 2020. Content Volunteers previously had the ability to edit protected pages via the Protect permission, prior to this wiki's migration to the UCP platform in October 2020.
 * Editprotected

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 being flagged as an Administrator are very small.

Fandom Staff, Fandom Helpers, and Administrators have the ability to rename categories. Registered Users also had the ability on C.Syde's Wiki for a short time, before the ability was subsequently revoked from them and granted to Assistants and Content Moderators in October 2020.
 * Move-categorypages

Deluxe Administrators were granted the ability to rename categories in December 2018, disregarding the fact that the ability had not been added to Fandom wikis in general until March 2020. The ability wasn't added to C.Syde's Wiki until the wiki was migrated to Fandom's Unified Community Platform in October 2020.

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 before Administrators were. However they should be careful when renaming categories, to make sure that any pages linking to the old name of the category are updated.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to move files, regardless if they didn't have Administrator rights or the wiki didn't allow files to be moved by non-administrators. 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 Movefile permission without being flagged as an Administrator are very small.
 * Movefile

Deluxe Administrators were granted the ability to move files in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to mark other users' edits as patrolled, regardless if they didn't have Administrator rights. 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 Patrol permission without being flagged as an Administrator are very small.
 * Patrol

Deluxe Administrators were granted the ability to mark other users' edits as patrolled in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators 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 it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to move pages without creating redirects from source pages, regardless if they didn't have Administrator rights. 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 Suppressredirect permission without being flagged as an Administrator are very small.
 * Suppressredirect

Deluxe Administrators were granted the ability to move pages without creating redirects from source pages in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it 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. 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 it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to use higher limits in API queries, regardless if they didn't have Administrator rights. 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 Apihighlimits permission without being flagged as an Administrator are very small.
 * Apihighlimits

Deluxe Administrators were granted the ability to use higher limits in API queries in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators 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 it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to move the blog articles of other users, regardless if they didn't have Administrator rights. 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-move permission without being flagged as an Administrator are very small.
 * Blog-articles-move

Deluxe Administrators were granted the ability to move the blog articles of other users in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators 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 it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to search deleted pages, regardless if they didn't have Administrator rights. 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 Browsearchive permission without being flagged as an Administrator are very small.
 * Browsearchive

Deluxe Administrators were granted the ability to search deleted pages in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to import pages from a file upload, regardless if they didn't have Administrator rights. 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 Importupload permission without being flagged as an Administrator are very small.
 * Importupload

Deluxe Administrators were granted the ability to import pages from a file upload in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

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

I was inspired to give Deluxe Administrators the ability to mark reverted edits as Bot edits because it is one of the optional abilities that can be accessed via the Quicktools permission which Deluxe Administrators already have. It was therefore decided that Deluxe Administrators should have full access to the abilities that come with the QuickTools extension, aside from the ability to quickly grant rights when approving adoption requests.

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 Markbotedits permission are very small.

Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, Spam Obliteration and Prevention members, and Assistants have the ability to be exempted from rate limits. Content Volunteers, Bots, Administrators, and Content Moderators also had the ability until May 2018 when it was removed from all the default local usergroups and Content Volunteers, due to the ability becoming more conservative due to abuse.
 * 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.

Assistants have the ability to override spoofing checks when renaming accounts. Admin Mentors, Bureaucrats, and Administrators also previously had the ability until sometime in 2015. It was removed from all default usergroups, most likely because the ability doesn't have any relevance to the current code base, since account registration was overhauled. As of 2015, certain custom usergroups on certain wikis are the only remaining usergroups that have the ability to override spoofing checks.
 * Override-antispoof

As such, there aren't any default usergroups with the permission on any wiki. Even though Deluxe Administrators were subsequently granted 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 outlived its use. This is further supported as the extension has not been enabled on Fandom 's Unified Community Platform.

Fandom Helpers, Spam Obliteration and Prevention members, Content Volunteers, and Assistants have the ability to override the title or username blacklist. Wiki Managers were subsequently granted the ability in December 2019.
 * Tboverride

Fandom Staff and Administrators also previously had the ability, prior to this wiki's migration to Fandom 's Unified Community Platform in October 2020. Volunteer Spam Task Force members also previously had the ability, prior to the usergroup's retirement.

The reason Fandom Staff and Administrators no longer have this ability is because the TitleBlacklist extension has not yet been enabled on UCP wikis. Deluxe Administrators were subsequently granted the ability to override the title or username blacklist so they wouldn't fall victim to them, should the extension ever be reenabled on UCP wikis and Administrators aren't immediately reinstated the ability to override the title or username blacklist.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to view the list of unwatched pages, regardless if they didn't have Administrator rights. 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 Unwatchedpages permission without being flagged as an Administrator are very small.
 * Unwatchedpages

Deluxe Administrators were granted the ability to view the list of unwatched pages in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to be eligible to earn Achievement points on wikis with Achievements enabled, regardless if they didn't have Administrator rights or if they had Fandom Staff, Wiki Manager, Content Team Member, Fandom Helper, or Spam Obliteration and Prevention rights. 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 Achievements-explicit permission without being flagged as an Administrator are very small.
 * Achievements-explicit

Deluxe Administrators were granted the ability to be eligible to earn Achievement points on wikis with Achievements enabled in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to access the analytics dashboard, regardless if they didn't have Administrator rights. 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 Analytics permission without being flagged as an Administrator are very small.
 * Analytics

Deluxe Administrators were granted the ability to access the analytics dashboard in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it 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 it 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 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 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 it 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.

Fandom Staff were eventually granted the ability to use Quicktools, following this wiki's migration to Fandom 's Unified Community Platform. 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.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to edit the wiki's mobile main page, regardless if they didn't have Administrator rights. 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 Curatedcontent permission without being flagged as an Administrator are very small.
 * Curatedcontent

Deluxe Administrators were granted the ability to edit the mobile main page in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Fandom Staff, Fandom Helpers, and Administrators have the ability to delete tags from the database. Deluxe Administrators were granted the ability to delete tags from the database in August 2020, 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.
 * Deletechangetags

Administrators were subsequently granted the ability to mass delete pages using the DynamicPageList on wikis that had the extension enabled in October 2020. Even though none of the usergroups on Fandom wikis were immediately granted the ability, the system messages related to the extension had appeared on wikis for quite some time before any of the permissions were added to any of the usergroups.
 * Dpl_param_delete_rules

For that reason, Deluxe Administrators were granted the ability to mass delete pages using the DynamicPageList in August 2020, in case the ability was ever added to usergroups on Fandom wikis. The ability is active on Gamepedia wikis, which explains why system messages related to the ability appeared on Fandom wikis prematurely.

The ability to mass delete pages using the DynamicPageList was already 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 ability ever be granted to usergroups on Fandom wikis. I was not expecting the ability to be granted to Administrators less than three months after I decided that it should be granted to Deluxe Administrators.

Administrators were subsequently granted the ability to mass update pages using the DynamicPageList on wikis that had the extension enabled in October 2020. Even though none of the usergroups on Fandom wikis were immediately granted the ability, the system messages related to the extension had appeared on wikis for quite some time before any of the permissions were added to any of the usergroups.
 * Dpl_param_update_rules

For that reason, Deluxe Administrators were granted the ability to mass update pages using the DynamicPageList in August 2020, in case the ability was ever added to usergroups on Fandom wikis. The ability is active on Gamepedia wikis, which explains why system messages related to the ability appeared on Fandom wikis prematurely.

The ability to mass update pages using the DynamicPageList was already 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 ability ever be granted to usergroups on Fandom wikis. I was not expecting the ability to be granted to Administrators less than three months after I decided that it should be granted to Deluxe Administrators.

Fandom Staff, Fandom Helpers, and Administrators have the ability to request database dumps on demand, via Special:Statistics. All three of these usergroups also have the Dumpsondemand permission, creating the impression that the Dumpsondemand and Dumpsondemandrequest permissions combined function the same way on Fandom 's Unified Community Platform that the Dumpsondemand permission alone did on the legacy platform.
 * Dumpsondemandrequest

Deluxe Administrators were granted the ability to request database dumps on demand in September 2020, since it was decided that they would receive various permissions extended to Administrators on UCP wikis that weren't extended to them on legacy wikis, until all wikis were 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.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it 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. 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.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to edit restricted form fields on wikis with the Page Forms extension enabled, regardless if they didn't have Administrator rights. 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 Editrestrictedfields permission without being flagged as an Administrator are very small.
 * Editrestrictedfields

Deluxe Administrators were granted the ability to edit restricted form fields in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, Spam Obliteration and Prevention members, Content Volunteers, Vanguards, Interface Administrators, and Administrators have the ability to edit CSS pages. Deluxe Administrators were granted the ability in March 2020, so they could edit CSS pages on UCP wikis without having to wait for Administrators to be granted the ability a month later.
 * Editsitecss

Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, Spam Obliteration and Prevention members, Content Volunteers, Vanguards, Interface Administrators, and Administrators have the ability to edit JavaScript pages. Deluxe Administrators were granted the ability in March 2020, so they could edit JavaScript pages on UCP wikis without having to wait for Administrators to be granted the ability nearly 5 months later.
 * Editsitejs

Fandom Staff, Fandom Helpers, Interface Administrators, and Administrators have the ability to edit JavaScript Object Notation pages. Deluxe Administrators were granted the ability in March 2020, so they could edit JavaScript Object Notation pages once all Fandom wikis were migrated to Fandom's Unified Community Platform. Since they already have the abilities to edit all system messages, which Administrators were able to do until August 2015.
 * Editsitejson

Fandom Staff, Fandom Helpers, Interface Administrators, and Administrators have the ability to edit and delete the personal JavaScript Object Notation pages belonging to other users. Deluxe Administrators were granted the ability in March 2020, so they could edit and delete other users' personal JavaScript Object Notation pages once all Fandom wikis were migrated to Fandom's Unified Community Platform.
 * Edituserjson

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 it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to create boards, regardless if they didn't have Administrator rights. 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 Forums:create permission without being flagged as an Administrator are very small.
 * Forums : create

Deluxe Administrators were granted the ability to create forum boards in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to delete boards, regardless if they didn't have Administrator rights. 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 Forums:delete permission without being flagged as an Administrator are very small.
 * Forums : delete

Deluxe Administrators were granted the ability to delete forum boards in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to change the display order of categories, regardless if they didn't have Administrator rights. 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 Forums:displayorder permission without being flagged as an Administrator are very small.
 * Forums : displayorder

Deluxe Administrators were granted the ability to change the display order of forum categories in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to edit boards, regardless if they didn't have Administrator rights. 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 Forums:edit permission without being flagged as an Administrator are very small.
 * Forums : edit

Deluxe Administrators were granted the ability to edit forum boards in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it 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.

Fandom Staff, Fandom Helpers, and Administrators have the ability to import pages from other wikis. Admin Mentors previously had the ability until sometime between July and November 2015 when the ability 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 Fandom Staff, Fandom Helpers, and Administrators had the ability to import pages from other wikis reinstated in October 2020, following this wiki's migration to Fandom's Unified Community Platform, the ability to import pages from other wikis remains disabled to this day. Whether it will ever be enabled on the Fandom network remains to be seen.

Fandom Staff, Fandom Helpers, and Administrators have the ability to create and deactivate tags. Deluxe Administrators were granted the ability to create and deactivate tags in August 2020, 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.
 * Managechangetags

Fandom Staff, Fandom Helpers, and Administrators were subsequently granted the ability to merge the history of two pages, following this wiki's migration to Fandom 's Unified Community Platform in October 2020.
 * Mergehistory

Deluxe Administrators were subsequently granted the ability to merge the history of two pages on wikis that had the Mergehistory extension enabled in May 2018, before being granted the permission by default in March 2020, upon hearing that Administrators would be granted the permission on UCP wikis. This means that Deluxe Administrators would have the ability to merge the history of two pages even if they don't have Administrator rights.

Since Deluxe Administrators are meant to be a more enhanced version of Administrators, it is obvious why Deluxe Administrators should have the ability to merge the history of pages, even if the permission isn't granted to Administrators, or if they don't have Administrator rights. However they should be careful when merging page histories, as the permission can be easily misused.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to bulk edit template types via category pages, regardless if they didn't have Administrator rights. 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 Template-bulk-classification permission without being flagged as an Administrator are very small.
 * Template-bulk-classification

Deluxe Administrators were granted the ability to bulk edit template types via category pages in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to design a theme for the wiki, regardless if they didn't have Administrator rights. 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 Themedesigner permission without being flagged as an Administrator are very small.
 * Themedesigner

Deluxe Administrators were granted the ability to design a theme for the wiki in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Administrators have the ability to view information about current transcode activities. Deluxe Administrators were granted the ability to view information about current transcode activities in August 2020, 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.
 * Transcode-status

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it 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, 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 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.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, since it would allow Deluxe Administrators to enable and disable certain wiki extensions, regardless if they didn't have Administrator rights. 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 Wikifeatures permission without being flagged as an Administrator are very small.
 * Wikifeatures

Deluxe Administrators were granted the ability to enable and disable certain wiki extensions in November 2020, when I ultimately decided to grant virtually all of the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than to allow myself to get locked in a repetitive cycle of continually adding individual administrative abilities to the Deluxe Administrator usergroup upon discovering that certain permissions already extended to them as a standalone group were dependent on other administrative abilities that weren't already extended to them.

Fandom Staff have the ability to edit and delete the personal CSS pages belonging to other users. Interface Administrators were also granted the ability, following their introduction in October 2020. Fandom Helpers and Administrators previously had the ability until August 2015 when it was removed from both usergroups due to security reasons. 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.

Fandom Staff have the ability to edit and delete the personal JavaScript pages belonging to other users. Interface Administrators were also granted the ability, following their introduction in October 2020. Fandom Helpers and Administrators previously had the ability until August 2015 when it was removed from both usergroups due to security reasons. 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 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 abilities to delete and undelete pages, Spam Obliteration and Prevention members were granted the ability 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, when the usergroup was introduced in July 2020. Fandom Staff, Wiki Managers, and Fandom Helpers were also subsequently granted the ability, following this wiki's migration to Fandom 's Unified Community Platform in October 2020.
 * Deleterevision

Fandom Utilities had this ability, prior to this wiki's migration to UCP. Volunteer Spam Task Force members also previously had the ability, prior to the usergroup's retirement. Once a revision is hidden, users without the Deletedhistory and Deletedtext permissions cannot view them, and users without the permission cannot restore them. 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.

This is probably one of the abilities that many Administrators would want to have the most. Fandom Utilities have the ability to edit, move, delete, and undelete all MediaWiki messages. Fandom Helpers were subsequently granted the ability to edit, move, delete, and undelete all MediaWiki messages in November 2016. Wiki Managers, Content Team Members, and Spam Obliteration and Prevention members were also granted the ability to edit, move, delete, and undelete all MediaWiki messages, following their respective introductions in May and July 2019, and July 2020. Fandom Staff were also subsequently granted the ability to edit, move, delete, and undelete all MediaWiki messages, following this wiki's migration to Fandom 's Unified Community Platform in October 2020.
 * Editinterfacetrusted

Volunteer Spam Task Force members also previously had the ability to edit, move, delete, and undelete all MediaWiki messages, prior to the usergroup's retirement. Administrators and Admin Mentors previously had the ability to edit, move, delete, and undelete all MediaWiki messages via the Editinterface permission 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 was added in August 2015 and functions the same way Editinterface did up until then, allowing users with the permission to edit, move, delete, and undelete any messages in the MediaWiki namespace. However only Fandom Utilities and Volunteer Spam Task Force members were immediately 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.

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.

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 the 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 the 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.

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 the 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 the 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 limit actions that can be performed for some groups for a limited time with the Protectsite permission, 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. 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.
 * Protectsite-exempt

Fandom Staff previously had the ability to be exempted from sitewide action restrictions. Administrators were also subsequently granted the ability on local wikis in April 2019. Both usergroups lost the ability, following this wiki's migration to Fandom 's Unified Community Platform in October 2020.

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. The reason Fandom Staff and Administrators lost the ability is most likely due to the permission not being active on UCP wikis yet.

In addition to the ability to delete pages, Fandom Helpers were subsequently granted the ability to quickly block users, and revert and delete spam and vandalism with quick tools 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. Fandom Staff were also subsequently granted the ability, following this wiki's migration to Fandom 's Unified Community Platform in October 2020.
 * Quicktools

Volunteer Spam Task Force members were also previously able to quickly block users, and revert and delete spam and vandalism with quick tools, prior to the usergroup's retirement. Fandom Utilities also previously had access to Quicktools, prior to this wiki's migration to UCP. However they weren't able to quickly block users, and revert and delete spam and vandalism as a standalone usergroup, as those actions required the Block, Rollback, and Delete permissions which Utilities didn't have. Administrators do not have this ability, likely because it is only meant to be used to combat spam and vandalism.

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 create and 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.

Fandom Staff and Fandom Helpers have the ability to show and hide the contents of specific log entries, the summaries of the log entries, the names of the users/IP addresses that made the log entries, or any combination of those three. Fandom Utilities and Spam Obliteration and Prevention members previously had the ability to show and hide specific log entries via the permission, prior to this wiki's migration to Fandom's Unified Community Platform in October 2020.
 * Deletelogentry

Volunteer Spam Task Force members also previously had the ability to show and hide specific log entries via the Deleterevision permission, prior to the usergroup's retirement. Once a log entry is hidden, users without the Deletedhistory and Deletedtext permissions cannot view them, and users without the Deleterevision and Deletelogentry permissions cannot restore them. Administrators do not have this ability on Fandom wikis, 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 grant to communities on request.

Though I had been battling with the idea of giving Deluxe Administrators the ability to show and hide specific log entries since Fandom's Unified Community Platform was first introduced, I finally decided in November 2020 that Deluxe Administrators should have the ability since Administrators have the ability by default on many other sites outside Fandom, including Gamepedia and. Furthermore, I later realised that the ability to show and hide specific log entries was previously extended to the Deleterevision permission. So Deluxe Administrators would have been able to show and hide specific log entries on the legacy platform.

Fandom Helpers have the ability to bypass automatic blocks of proxies. Wiki Managers and Content Team Members were also granted the ability, following their respective introductions in May and July 2019, and July 2020.
 * Proxyunbannable

Fandom Staff and Administrators also previously had the ability, prior to this wiki's migration to Fandom 's Unified Community Platform in October 2020.

The reason Fandom Staff and Administrators no longer have this ability is because it hasn't been added to UCP wikis. 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, should the extension ever be reenabled on UCP wikis and Administrators aren't immediately reinstated the ability to bypass proxy blocks.

Fandom Helpers have the ability to access Semantic MediaWiki administration tasks on wikis with Semantic MediaWiki enabled. Wiki Managers were subsequently granted the ability to access Semantic MediaWiki administration tasks in December 2019. Fandom Staff and Administrators also previously had the ability, prior to this wiki's migration to Fandom 's Unified Community Platform in October 2020.
 * Smw-admin

The reason Fandom Staff and Administrators no longer have this ability is because the Semantic MediaWiki extension has not yet been enabled on UCP wikis. Deluxe Administrators were subsequently granted the ability in August 2020 so they would immediately be able to access Semantic MediaWiki administration tasks on wikis with Semantic MediaWiki enabled, once those wikis have been migrated to the UCP platform.

Fandom Helpers have the edit access to maintain allowed regular expressions and patterns on wikis with Semantic MediaWiki enabled. Wiki Managers were subsequently granted the ability to edit access to maintain allowed regular expressions and patterns in December 2019. Fandom Staff and Administrators also previously had the ability, prior to this wiki's migration to Fandom 's Unified Community Platform in October 2020.
 * Smw-patternedit

The reason Fandom Staff and Administrators no longer have this ability is because the Semantic MediaWiki extension has not yet been enabled on UCP wikis. Deluxe Administrators were subsequently granted the ability in August 2020 so they would immediately be able to edit access to maintain allowed regular expressions and patterns on wikis with Semantic MediaWiki enabled, once those wikis have been migrated to the UCP platform.

Wiki Managers have the ability to edit interwiki data. The reason Administrators do not have this ability on Fandom wikis is unclear. But there are two likely reasons as to why they don't have the permission on Fandom's Unified Community Platform. The first likely reason is that the ability could be misused very easily if Administrators were to have it by default. The second likely reason is that the Interwiki extension either hasn't been added to the UCP platform yet, or it hasn't been added to local UCP wikis.
 * Interwiki

The ability to edit interwiki data is extended to Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, and Administrators on Gamepedia wikis. The permission is also extended to Administrators on several other sites. For these reasons, Deluxe Administrators were subsequently granted the ability to edit interwiki data in November 2020, disregarding the fact that the ability has not yet been added to Fandom wikis in general.

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

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom 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 run arbitrary cargo queries, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were granted the ability to run arbitrary cargo queries, in case the extension is ever added to Fandom wikis.
 * Runcargoqueries

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom 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 view the spam blacklist log, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were granted the ability to view the spam blacklist log, in case the extension is ever added to Fandom wikis.
 * Spamblacklistlog

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom 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 edit spritesheets, sprites, slices, assign names, and delete, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were granted the ability to edit sprites, in case the extension is ever added to Fandom 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 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 perform administrator tasks on achievements, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were subsequently granted the ability to perform administrator tasks on achievements in November 2020, in case the extension is ever added to Fandom wikis.
 * Achievement_admin

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom wikis. The ability to perform administrator tasks on achievements is extended to Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, and 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 manually award or unaward achievements, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were subsequently granted the ability to manually award or unaward achievements in November 2020, in case the extension is ever added to Fandom wikis.
 * Award_achievements

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom wikis. The ability to manually award or unaward achievements is extended to Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, and 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 achievements, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were subsequently granted the ability to delete achievements in November 2020, in case the extension is ever added to Fandom wikis.
 * Delete_achievements

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom wikis. The ability to delete achievements is extended to Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, and 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 permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were granted the ability to delete cargo tables, in case the extension is ever added to Fandom wikis.
 * Deletecargodata

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom wikis. The ability to delete cargo tables is extended to Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, Spam Obliteration and Prevention members, and 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 achievements, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were subsequently granted the ability to edit achievements in November 2020, in case the extension is ever added to Fandom wikis.
 * Edit_achievements

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom wikis. The ability to edit achievements is extended to Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, and 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 meta style local achievements, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were subsequently granted the ability to edit meta style local achievements in November 2020, in case the extension is ever added to Fandom wikis.
 * Edit_meta_achievements

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom wikis. The ability to edit meta style local achievements is extended to Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, and 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 add and edit streamer information on, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were subsequently granted the ability to add and edit streamer information in November 2020, in case the extension is ever added to Fandom wikis.
 * Edit_streamer_info

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom wikis. The ability to add and edit streamer information 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 create and edit widgets in the Widget namespace, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were granted the ability to create and edit widgets in the Widget namespace, in case the extension is ever added to Fandom wikis.
 * Editwidgets

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom wikis. The ability to create and edit widgets in the Widget namespace is extended to Fandom Staff, Wiki Managers, Content Team Members, and 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 embed PDFs into pages, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were granted the ability to embed PDFs into pages, in case the extension is ever added to Fandom 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 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, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were granted the ability to manage custom fonts, in case the extension is ever added to Fandom 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 wikis. The ability to manage custom fonts is extended to Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, and 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 "Generate pages" tab and page, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were subsequently granted the ability to view the "Generate pages" tab and page in November 2020, in case the extension is ever added to Fandom wikis.
 * Generatepages

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom wikis. The ability to view the "Generate pages" tab and page 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 moderate user profiles, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were subsequently granted the ability to moderate user profiles in November 2020, in case the extension is ever added to Fandom wikis.
 * Profile-moderate

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom wikis. The ability to moderate user profiles is extended to Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, Spam Obliteration and Prevention members, and 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 purge comments on user profiles, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were subsequently granted the ability to purge comments on user profiles in November 2020, in case the extension is ever added to Fandom wikis.
 * Profile-purgecomments

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom wikis. The ability to purge comments on user profiles is extended to Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, and 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 permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were granted the ability to recreate data contained in cargo tables, in case the extension is ever added to Fandom wikis.
 * Recreatecargodata

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom wikis. The ability to recreate data contained in cargo tables is extended to Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, Spam Obliteration and Prevention members, and 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 restore deleted achievements, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were subsequently granted the ability to restore deleted achievements in November 2020, in case the extension is ever added to Fandom wikis.
 * Restore_achievements

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom wikis. The ability to restore deleted achievements is extended to Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, and 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 overwrite existing files uploaded by oneself. However the permission does exist on Fandom wikis, according to the system messages referring to usergroup rights. The reason none of the usergroups have this permission is most likely because its purpose is covered by the Reupload permission which is extended to Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, Spam Obliteration and Prevention members, Content Volunteers, Administrators, Content Moderators, and Registered Users. The Reupload-own permission is extended to Administrators on Gamepedia wikis, however.
 * Reupload-own

Deluxe Administrators were subsequently granted the ability to overwrite existing files uploaded by oneself in November 2020, 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 overwrite existing files uploaded by oneself on wikis that don't allow files to be overwritten by non-administrators. 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 Reupload-own permission without the Upload and Reupload permissions are very small.

None of the usergroups on Fandom wikis have the ability to revert spritesheet changes from the change log, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were granted the ability to revert spritesheet changes from the change log, in case the extension is ever added to Fandom 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 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 view the title blacklist log, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were granted the ability to view the title blacklist log, in case the extension is ever added to Fandom wikis.
 * Titleblacklistlog

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom 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 configure Upload Wizard campaigns, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were subsequently granted the ability to configure Upload Wizard campaigns in November 2020, in case the extension is ever added to Fandom wikis.
 * Upwizcampaigns

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom wikis. The ability to configure Upload Wizard campaigns 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 user wiki points history, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were subsequently granted the ability to view the user wiki points history in November 2020, in case the extension is ever added to Fandom wikis.
 * Wiki_points_admin

Also the extension is active on Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom wikis. The ability to view the user wiki points history is extended to Fandom Staff, Wiki Managers, Content Team Members, Fandom Helpers, and 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 batches of pages, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were granted the ability to batch delete pages, in case the extension is ever added to Fandom 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 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.

None of the usergroups on Fandom wikis have the ability to upload fonts using the, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were granted the ability to upload custom fonts, in case the extension is ever added to Fandom 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 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 edit gadget definitions. However the permission does exist on Fandom's Unified Community Platform. The reason none of the usergroups on Fandom UCP wikis with the Gadgets extension enabled have the ability to edit gadget definitions is because the extension is not currently ready to be used by UCP communities.
 * Gadgets-definition-edit

Deluxe Administrators were granted the ability to edit gadget definitions in October 2020 so they wouldn't have to wait for the ability to be granted to Administrators. But like all permissions that are currently restricted, Deluxe Administrators need to be careful to avoid making any changes to gadget definitions that could potentially create security issues.

None of the usergroups on Fandom wikis have the ability to edit gadget CSS and JavaScript pages. However the permission does exist on Fandom's Unified Community Platform. The reason none of the usergroups on Fandom UCP wikis with the Gadgets extension enabled have the ability to edit gadget CSS and JavaScript pages is because the extension is not currently ready to be used by UCP communities.
 * Gadgets-edit

Deluxe Administrators were granted the ability to edit gadget CSS and JavaScript pages in October 2020 so they wouldn't have to wait for the ability to be granted to Administrators. But like all permissions that are currently restricted, Deluxe Administrators need to be careful to avoid making any changes to gadget CSS and JavaScript pages that could potentially create security issues.

None of the usergroups on Fandom wikis have the ability to batch upload more files at once with the Upload Wizard, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were granted the ability to batch upload more files at once, in case the extension is ever added to Fandom 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 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 change the page language for MediaWiki pages. However the permission does exist on Fandom wikis, according to the system messages referring to usergroup rights. The reason Administrators do not have this ability on Fandom wikis is unclear. But there are two likely reasons as to why they don't have the permission on Fandom's Unified Community Platform. The first likely reason is that the ability could be misused very easily if Administrators were to have it by default.
 * Pagelang

The second likely reason is that the permission hasn't been set up on the UCP platform yet. Usergroups with the Managewiki permission on wikis are able to grant the Pagelang permission to local usergroups. Also the ability is usually granted to Administrators on sites that make use of the permission. For these reasons, I subsequently decided to grant Deluxe Administrators the ability to change the page language for MediaWiki pages in November 2020.

None of the usergroups on Fandom wikis have the ability to view recent changes patrol marks. However the permission does exist on Fandom wikis, according to the system messages referring to usergroup rights. The reason none of the usergroups have this permission 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.

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.

None of the usergroups on Fandom wikis have the ability to create skins for categories, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis. Deluxe Administrators were subsequently granted the ability to create skins for categories in November 2020, in case the extension is ever added to Fandom wikis.
 * Skincategories

Also the extension is active on certain Gamepedia wikis, which probably explains why system messages related to the extension have appeared on Fandom wikis. The ability to create skins for categories is extended to Administrators on certain 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 access for Is edit protected annotated pages on wikis with Semantic MediaWiki enabled, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis, though the extension itself has not yet been enabled on Fandom 's Unified Community Platform.
 * Smw-pageedit

Deluxe Administrators were subsequently granted the ability in November 2020 so they would immediately have edit access for Is edit protected annotated pages on wikis with Semantic MediaWiki enabled, once those wikis have been migrated to the UCP platform. However it is unknown which usergroups the Smw-pageedit permission will be granted to on Fandom wikis with Semantic MediaWiki enabled, or if the permission will ever be granted altogether.

None of the usergroups on Fandom wikis have the ability to edit rule pages on wikis with Semantic MediaWiki enabled, as the permission has never existed on Fandom wikis. Despite this, the system messages related to the extension do appear on Fandom wikis, though the extension itself has not yet been enabled on Fandom 's Unified Community Platform.
 * Smw-ruleedit

Deluxe Administrators were subsequently granted the ability in November 2020 so they would immediately be able to edit rule pages on wikis with Semantic MediaWiki enabled, once those wikis have been migrated to the UCP platform. However it is unknown which usergroups the Smw-ruleedit permission will be granted to on Fandom wikis with Semantic MediaWiki enabled, or if the permission will ever be granted altogether.

None of the usergroups on Fandom wikis have the ability to override the username blacklist. However the permission does exist on Fandom wikis, according to the system messages referring to usergroup rights. The reason none of the usergroups had the permission on Fandom's legacy platform is unclear. But there are two likely reasons as to why none of the usergroups have the permission on the Unified Community Platform.
 * Tboverride-account

The first likely reason is that the purpose of the Tboverride-account permission is also covered by the Tboverride permission. The second likely reason is that neither of those permissions and the associated TitleBlacklist extension have been added to the UCP platform yet.

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. Though one could argue that Deluxe Administrators having this permission on UCP wikis is redundant, as they already have the Tboverride permission.

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 Autopatrolled rights from other users, after it was decided that they should be able to grant and revoke any local usergroup permissions below Administrator.
 * Autopatrolled Users

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 Discussion Moderator rights from other users, after it was decided that they should be able to grant and revoke any local usergroup permissions below Administrator.
 * Discussion 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.

Deluxe Administrators were subsequently granted the ability to add and remove Bot rights to and from their own account, should they ever need to perform mass deletions or edits without flooding recent changes. I was inspired to give Deluxe Administrators the ability to add and remove Bot rights to and from their own account because it is one of the optional abilities that can be accessed via the Quicktools permission which Deluxe Administrators already have.
 * Bots

It was therefore decided that Deluxe Administrators should have full access to the abilities that come with the QuickTools extension, aside from the ability to quickly grant rights when approving adoption requests. Though Deluxe Administrators should only bot themselves when performing mass deletions or edits, or quickly reverting and deleting spam and vandalism. Most other instances are considered to be abusive. Deluxe Administrators that abuse the privilege of botting themselves may have their rights revoked by Staff.

Groups that Deluxe Administrators are able to remove from their own account
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 and log entries, the summaries of the revisions and log entries, the names of the users/IP addresses that made the edits and log entries, 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.

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. On wikis with the AbuseFilter 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 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.