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.

All Users have the ability to create blog articles. However since anonymous editing is disabled on this wiki, the ability to create blog articles is restricted to Registered Users and up, as is the ability to edit pages. And even when Unregistered Users were able to edit pages on this wiki prior to August 2015, they couldn't create blog articles. Administrators do not have the ability, likely because they implicitly have all the permissions extended to Registered and Unregistered Users, and therefore it would be redundant for them to have the permission as a standalone group.
 * Blogs : create

Deluxe Administrators were subsequently granted the ability to create blog articles in February 2020, so they would be able to create blog articles on wikis that have restricted the ability to create blog articles, such as the Community Central Wiki. Deluxe Administrators are supposed to have editing access in all namespaces on all wikis with few exceptions, usually hidden wikis like the Community Council Wiki. Therefore, I wanted to ensure that they would still be able to edit the namespaces that are restricted on certain wikis.

Fandom Staff and All Users have the ability to create new user accounts. Fandom Helpers and Administrators were subsequently granted the ability to create new user accounts, following this wiki's migration to Fandom 's Unified Community Platform in October 2020.
 * Createaccount

Deluxe Administrators were subsequently granted the ability to create new user accounts in late December 2020 since it was decided that they would be granted all the abilities that they previously wouldn't have been able to access as a standalone group on wikis that are currently protected with the Protectsite permission.

However, Deluxe Administrator rights are only granted to experienced and trusted users that are currently Administrators, and the users that are granted Deluxe Administrator rights are expected to retain their Administrator rights while they are Deluxe Administrators.

Fandom Helpers, Registered Users, and All Users have the ability to create pages that are not discussion pages. Wiki Representatives, Wiki Specialists, and Spam Obliteration and Prevention members were also granted the ability to create pages that are not discussion pages, following their respective introductions in May and July 2019, and July 2020. Volunteer Spam Task Force members also previously had the ability to create pages that are not discussion pages, prior to the usergroup's retirement.
 * Createpage

Deluxe Administrators were subsequently granted the ability to create pages that are not discussion pages in late December 2020 since it was decided that they would be granted all the abilities that they previously wouldn't have been able to access as a standalone group on wikis that are currently protected with the Protectsite permission. However, Deluxe Administrator rights are only granted to experienced and trusted users that are currently Administrators, and the users that are granted Deluxe Administrator rights are expected to retain their Administrator rights while they are Deluxe Administrators.

Fandom Helpers, Registered Users, and All Users have the ability to create discussion pages. Wiki Representatives, Wiki Specialists, and Spam Obliteration and Prevention members were also granted the ability to create discussion pages, following their respective introductions in May and July 2019, and July 2020. Volunteer Spam Task Force members also previously had the ability to create discussion pages, prior to the usergroup's retirement.
 * Createtalk

Deluxe Administrators were subsequently granted the ability to create discussion pages in late December 2020 since it was decided that they would be granted all the abilities that they previously wouldn't have been able to access as a standalone group on wikis that are currently protected with the Protectsite permission. However, Deluxe Administrator rights are only granted to experienced and trusted users that are currently Administrators, and the users that are granted Deluxe Administrator rights are expected to retain their Administrator rights while they are Deluxe Administrators.

Fandom Helpers and Registered Users have the ability to edit pages. Wiki Representatives and Wiki Specialists were also granted the ability to edit pages, following their respective introductions in May and July 2019. All Users also previously had the ability to edit pages, prior to anonymous editing being disabled on this wiki in August 2015.
 * Edit

Deluxe Administrators were subsequently granted the ability to edit pages in late December 2020 since it was decided that they would be granted all the abilities that they previously wouldn't have been able to access as a standalone group on wikis that are currently protected with the Protectsite permission.

However, Deluxe Administrator rights are only granted to experienced and trusted users that are currently Administrators, and the users that are granted Deluxe Administrator rights are expected to retain their Administrator rights while they are Deluxe Administrators.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have the ability to move pages as a standalone group.
 * Move

In late December 2020, I decided that Deluxe Administrators would be granted all the abilities that they previously wouldn't have been able to access as a standalone group on wikis that are currently protected with the Protectsite permission.

However, Deluxe Administrator rights are only granted to experienced and trusted users that are currently Administrators, and the users that are granted Deluxe Administrator rights are expected to retain their Administrator rights while they are Deluxe Administrators.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have the ability to overwrite existing files as a standalone group.
 * Reupload

In late December 2020, I decided that Deluxe Administrators would be granted all the abilities that they previously wouldn't have been able to access as a standalone group on wikis that are currently protected with the Protectsite permission.

However, Deluxe Administrator rights are only granted to experienced and trusted users that are currently Administrators, and the users that are granted Deluxe Administrator rights are expected to retain their Administrator rights while they are Deluxe Administrators.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have the ability to locally override files on the shared media repository as a standalone group.
 * Reupload-shared

In late December 2020, I decided that Deluxe Administrators would be granted all the abilities that they previously wouldn't have been able to access as a standalone group on wikis that are currently protected with the Protectsite permission.

However, Deluxe Administrator rights are only granted to experienced and trusted users that are currently Administrators, and the users that are granted Deluxe Administrator rights are expected to retain their Administrator rights while they are Deluxe Administrators.

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have the ability to upload files as a standalone group.
 * Upload

In late December 2020, I decided that Deluxe Administrators would be granted all the abilities that they previously wouldn't have been able to access as a standalone group on wikis that are currently protected with the Protectsite permission.

However, Deluxe Administrator rights are only granted to experienced and trusted users that are currently Administrators, and the users that are granted Deluxe Administrator rights are expected to retain their Administrator rights while they are Deluxe Administrators.

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.
 * Skipcaptcha

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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.
 * Autoconfirmed

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

Fandom Staff, Wiki Representatives, Wiki Specialists, 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.

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.
 * Transcode-reset

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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.
 * Autopatrol

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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. Bots, Discussion Moderators, Rollbackers, and Autopatrolled Users were subsequently granted the ability on C.Syde's Wiki in April 2021.
 * 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. However Deluxe Administrators 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.
 * Movefile

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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.
 * Suppressredirect

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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.

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.
 * Admindashboard

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

Fandom Staff, Wiki Representatives, Wiki Specialists, 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.

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

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

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.
 * ModeratorTools : use

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

Fandom Staff, Wiki Representatives, 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. Content Moderators were subsequently granted the ability to delete and undelete article and blog comments in November 2020. 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.

Fandom Staff, Wiki Representatives, 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. Volunteer Spam Task Force members also had the ability to delete all posts by a specific user, prior to the usergroup's retirement.
 * Posts : deleteall

Content Moderators were subsequently granted the ability to delete all posts by a specific user in April 2021. 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.

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.
 * Posts : lock

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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.
 * Posts : superedit

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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.
 * Posts : validate

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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

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.

Global Discussion Moderators, Administrators, and Discussion Moderators have the ability to delete and undelete message wall messages and discussion posts. Fandom Staff, Wiki Representatives, 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. Content Moderators were subsequently granted the ability in April 2021. 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.

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.
 * Threads : lock

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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.
 * Threads : move

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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.
 * Threads : superedit

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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

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.

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.

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

Fandom Staff, Wiki Representatives, Wiki Specialists, 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. 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.
 * Editcontentmodel

Fandom Staff, Wiki Representatives, Wiki Specialists, 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.

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.
 * Patrol

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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

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

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.
 * Apihighlimits

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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

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.
 * Blog-articles-move

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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

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.
 * Browsearchive

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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.
 * Importupload

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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 Wiki Specialists.
 * 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.

Fandom Staff, Wiki Representatives, Wiki Specialists, 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, Administrators, and Assistants have the ability to override the title or username blacklist. Wiki Representatives were subsequently granted the ability in December 2019. Fandom Staff 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.
 * Tboverride

The reason Fandom Staff and Administrators lost the ability was because the TitleBlacklist extension had 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 have ever been reenabled on UCP wikis and Administrators weren't immediately reinstated the ability to override the title or username blacklist. Administrators subsequently regained the ability to override the title or username blacklist when the extension was reenabled in February 2021.

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.
 * Unwatchedpages

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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 Representative, Wiki Specialist, Fandom Helper, or Spam Obliteration and Prevention rights.
 * Achievements-explicit

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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.
 * Analytics

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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.

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.
 * Block

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

Even though this ability is already included with the Administrator usergroup, I subsequently decided that Deluxe Administrators should have it as a standalone group. I was inspired to do this, because even though the ListGroupRights special page implies that Fandom Staff, Wiki Representatives, 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 Representatives, Wiki Specialists, 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.
 * Curatedcontent

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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

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

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.
 * Editrestrictedfields

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

Fandom Staff, Wiki Representatives, Wiki Specialists, 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 Representatives, Wiki Specialists, 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.
 * Forums : create

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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.
 * Forums : delete

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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.
 * Forums : displayorder

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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.
 * Forums : edit

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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

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 Representatives were subsequently granted the ability in July 2019, as were Wiki Specialists when the usergroup was introduced in July 2019 on the same day. Because Wiki Representatives and Wiki Specialists 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.
 * 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. Wiki Representatives were subsequently granted the ability in April 2021.
 * 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. 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.
 * Template-bulk-classification

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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.
 * Themedesigner

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

Administrators were subsequently granted the ability to view the title blacklist log in February 2021. 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.
 * Titleblacklistlog

For that reason, Deluxe Administrators were granted the ability to view the title blacklist log 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 view the title blacklist log 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 half a year after I decided that it should be granted to Deluxe Administrators.

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.
 * 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.
 * Wikifeatures

I decided in November 2020 to grant virtually all the Administrator permissions that still function to the Deluxe Administrator usergroup, rather than allow myself to be 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 were dependent on other administrative abilities that they didn't already have.

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 Representatives and Wiki Specialists 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.

But like the other permissions that Deluxe Administrators have that are only extended to global usergroups, they 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 Representatives, 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.

But like the other permissions that they 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 Representatives, Wiki Specialists, 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 search for pages on all wikis, Fandom Staff and Fandom Helpers are able to search for a specific title across Fandom wikis. Volunteer Spam Task Force members also had the ability, prior to the usergroup's retirement. Wiki Representatives were subsequently granted the ability in December 2019, and Spam Obliteration and Prevention members were granted the ability, following their introduction in July 2020. Administrators do not have this ability, likely to prevent them from using it to find all the wikis that a certain user contributed to.
 * Multiwikifinder

Unlike Administrators, Deluxe Administrators were subsequently granted the ability to search for a specific title across Fandom in December 2020. I felt that since users now have the option to search for pages on all wikis that Deluxe Administrators should be granted the ability to search for a specific title across Fandom wikis. Even though Deluxe Administrators are able to search for a specific title across Fandom, they should only use this ability to check what other wikis that a local vandal has targeted. Deluxe Administrators can have their rights revoked by Staff if they are found to have abused the privilege of searching for a specific title across Fandom.

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 Representatives and Wiki Specialists 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 Wiki Specialists 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.

But like the other permissions that Deluxe Administrators have that are only extended to global usergroups, they shouldn't use Nuke for simple disagreements between users that are acting in good faith. Deluxe Administrators 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 Representatives 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.

But like the other permissions that Deluxe Administrators have that are only extended to global usergroups, they shouldn't protect wikis for simple disagreements between users that are acting in good faith. Deluxe Administrators should only use it against excessive spam or vandalism. They may 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, Fandom Staff, Wiki Representatives, Wiki Specialists, 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

Administrators were also subsequently granted the ability on local wikis in April 2019. Both they and Fandom Staff 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 was primarily due to Fandom's version of the extension not being active on UCP wikis yet.

Fandom Staff subsequently regained the ability to be exempted from sitewide action restrictions when Fandom's version of the extension was reenabled in February 2021. It is unknown if Administrators will ever regain the ability to be exempted from sitewide restrictions.

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 Representatives, Wiki Specialists, 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.

But like the other permissions that Deluxe Administrators have that are only extended to global usergroups, they 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 Representatives, and Wiki Specialists 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.

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 Staff and Fandom Helpers have the ability to edit interlanguage links for web-based handling. Wiki Representatives were subsequently granted the ability in July 2019. Administrators do not have this ability, partly because it wouldn't be appropriate for local usergroups to have editing access to interwiki data.
 * InterwikiEdit

Also the extension doesn't appear on any legacy wikis besides the Community Central Wiki, so it would be largely pointless if Administrators were to have it anyway. Administrators on the Community Central Wiki however do have access to the InterwikiEdit special page. For that reason, I was inspired to grant Deluxe Administrators the ability to edit interlanguage links.

In addition to the ability to limit actions that can be performed for some groups for a limited time, Fandom Helpers have the ability to limit actions that can be performed for some groups for any length of time. Wiki Representatives were subsequently granted the ability in December 2019. Fandom Staff also previously had the ability to be exempted from site protection limits, prior to this wiki's migration to Fandom 's Unified Community Platform in October 2020.
 * Protectsite-nolimit

The reason Fandom Staff lost the ability was primarily due to Fandom's version of the ProtectSite extension not being active on UCP wikis yet. Even though Fandom's version of the extension was reenabled in February 2021, Fandom Staff haven't regained the ability to be exempted from site protection limits, though it is extremely likely that they will eventually regain it.

Administrators do not have this ability, because they don't have the Protectsite permission on Fandom wikis by default, and even if they did, the ability to be exempted from site protection limits would be abused too easily and too frequently if Administrators were to have it. Deluxe Administrators were subsequently granted the ability in December 2020, because they could already bypass most restrictions that Administrators can't bypass, and since the Deluxe Administrator usergroup is only granted to highly experienced and trusted Administrators, I felt that having them bypass a couple more restrictions wouldn't hurt.

But like the other permissions that Deluxe Administrators have that are only extended to global usergroups, they shouldn't use the ability to limit actions that can be performed for some groups for any length of time except in extreme circumstances. Deluxe Administrators can have their rights revoked by Fandom Staff if they are found to have used the abilities to limit actions that can be performed for some groups both for a limited time and for any length of time.

Fandom Helpers have the ability to bypass automatic blocks of proxies. Wiki Representatives and Wiki Specialists were also granted the ability, following their respective introductions in May and July 2019, and July 2020. Fandom Staff and Administrators also previously had the ability, prior to this wiki's migration to Fandom 's Unified Community Platform in October 2020.
 * Proxyunbannable

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 Staff and Wiki Representatives have the ability to edit and  pages. Wiki Specialists, Fandom Helpers, Spam Obliteration and Prevention members, Content Volunteers, Vanguards, Interface Administrators, and Administrators were able to edit FandomMobile.css and FandomMobile.js pages via the Editinterface, Editsitecss, and Editsitejs permissions, prior to the introduction of the Edit-fandommobile-customizations permission.
 * Edit-fandommobile-customizations

Deluxe Administrators were subsequently granted the ability to edit FandomMobile.css and FandomMobile.js pages in December 2020, so they wouldn't be restricted from editing them. Since Administrators were once able to edit virtually all pages in all namespaces, I wanted to ensure that Deluxe Administrators would be able to retain editing access to all pages in all namespaces.

But like the other permissions that they have that are only extended to global usergroups, Deluxe Administrators should only make changes to FandomMobile.css and FandomMobile.js pages that have been approved either by Administrators or the general community. They should also be careful to avoid making any changes that would break the customisation policy. Deluxe Administrators may have their rights revoked by Staff if they are found to have abused the privilege of editing FandomMobile.css and FandomMobile.js pages.

Wiki Representatives 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 Representatives, Wiki Specialists, 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.

Content Reviewers have the ability to review, approve, and reject sitewide JavaScript via the Content-review permission. They could also have their edits to sitewide JavaScript automatically marked as approved. Before the JavaScript review process was introduced in September 2015, and before edits to sitewide JavaScript became restricted in August 2015, Fandom Staff, Fandom Helpers, Volunteer Spam Task Force members, Admin Mentors, and Administrators were able to edit sitewide JavaScript and automatically have their edits to sitewide JavaScript be served to the community.
 * Content-review-local

Deluxe Administrators were subsequently granted an ability to review, approve, and reject local sitewide JavaScript that hadn't yet been reviewed by a member of the content review team, so they wouldn't have to wait for a content reviewer to review it. Since Administrators were able to edit sitewide JavaScript and automatically have their edits to sitewide JavaScript be served to the community until August 2015, I felt that Deluxe Administrators should be able to review, approve, and reject local sitewide JavaScript, so they won't be barred by the same restrictions as the other users that don't have Content Review rights.

Normally I would consider such an ability to be too overpowered for Deluxe Administrators to get away with. But since Administrators weren't barred by the restrictions of the JavaScript review process, prior to August 2015, and Administrators have to be highly trusted and experienced in order to be granted Deluxe Administrator rights by Staff, I felt that as long as the prospective Deluxe Administrators had demonstrated experience with distinguishing safe JavaScript from unsafe JavaScript, I felt that I could make an exception for the Deluxe Administrator usergroup.

Deluxe Administrators that are found to have approved unsafe JavaScript may have their rights revoked by Staff. In situations where a Deluxe Administrator is unsure if certain unreviewed JavaScript is safe or not, they are expected to leave the unreviewed JavaScript for a member of the content review team to review. Otherwise they are free to reject the unreviewed JavaScript themselves.

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 gadget definition namespace doesn't do anything.
 * Gadgets-definition-edit

The gadget definition namespace was added by the gadgets extension for planned development that never happened to this day. 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. I was unaware at the time that the permission was not intended to be granted to any usergroups, and that gadget editing on UCP wikis would remain in the MediaWiki namespace like on Legacy.

Deluxe Administrators are supposed to have editing access in all namespaces, which is why they haven't lost the ability to edit gadget definitions, even after I discovered that none of the usergroups on Fandom wikis were intended to be granted the ability. 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 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 gadget namespace doesn't do anything.
 * Gadgets-edit

The gadget namespace was added by the gadgets extension for planned development that never happened to this day. 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. I was unaware at the time that the permission was not intended to be granted to any usergroups, and that gadget editing on UCP wikis would remain in the MediaWiki namespace like on Legacy.

Deluxe Administrators are supposed to have editing access in all namespaces, which is why they haven't lost the ability to edit gadget CSS and JavaScript pages, even after I discovered that none of the usergroups on Fandom wikis were intended to be granted the ability. 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.

Fandom Staff and Fandom Helpers have the ability to delete many pages on a single wiki via the Multidelete permission. Volunteer Spam Task Force members also had the ability, prior to the usergroup's retirement. Wiki Representatives were subsequently granted the ability in December 2019, and Spam Obliteration and Prevention members were granted it, following their introduction in July 2020. Administrators do not have the ability, because in addition to deleting many pages on a single wiki, it also allows users to delete one page across many wikis, and is thus restricted to certain global usergroups.
 * Multideletelocal

Even though I'm pretty sure the Multidelete permission wouldn't be able to delete pages across many wikis unless the user had the Delete permission on those wikis, there are other things that prevent it from being considered for local usergroups. One is that the permission is considered to be overpowered for local usergroups, even if it could only be used on individual wikis. Another is that the Multidelete permission allows users to choose between deleting pages under their own account, or under the Maintenance script. In the case of the latter, users would be able to delete stuff using the Maintenance script, even if the user themselves didn't have the Delete permission. The Maintenance script is able to delete stuff even without the Delete permission.

Deluxe Administrators were subsequently granted an ability to delete many pages on a single wiki, either under their own account or as the Maintenance script. However unlike the Multidelete permission, the fictitious Multideletelocal ability would not allow users to delete a page across many wikis, although it would allow them to delete one page on the wiki where the action is being performed. The reason I subsequently decided that Deluxe Administrators should have a localised version of the Multidelete permission was so that they'd be able to delete many pages at once on any wiki where they have Deluxe Administrator rights, and the DeleteBatch extension which has similar functions has not been enabled.

None of the usergroups on Fandom wikis have the ability to export pages including linked pages up to a depth of 5. 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 unclear, though it could just be that the permission hasn't been added to any usergroups on the UCP platform yet.
 * Override-export-depth

Deluxe Administrators were subsequently granted the ability to export pages including linked pages up to a depth of 5 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.

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.

Fandom Staff and Fandom Helpers have the ability to override the spam blacklist via the Phalanxexempt permission. Volunteer Spam Task Force members also had the ability, prior to the usergroup's retirement. Wiki Representatives, Wiki Specialists, and Spam Obliteration and Prevention members were also granted it, following their respective introductions in May and July 2019, and July 2020. Administrators do not have the ability, because in addition to overriding the spam blacklist, it also makes users immune to global blocks. And even then, the ability would be abused too easily and too frequently if Administrators were to have it.
 * Sboverride

Deluxe Administrators were subsequently granted an ability to override the spam blacklist. However unlike the Phalanxexempt permission, the Sboverride ability would not make users immune to global blocks. The reason I subsequently decided that Deluxe Administrators should have an ability to override the spam blacklist was so that they wouldn't fall victim to any false positives by the spam protection filter while editing.

Even though Deluxe Administrators were subsequently granted an ability to override the spam blacklist, they are expected to take note of the blacklist entries that would otherwise trigger the spam protection filter. They may only override the spam blacklist for minor issues such as creating the userpage for the SOAP Bot. Deluxe Administrators can have their rights revoked by Staff if they are found to have abused the privilege of overriding the spam blacklist by doing things such as inserting content that would not only have triggered the spam protection filter but is in violation of Fandom's terms of use.

Even though I got the idea in February 2021 to create a fictional ability that allows users to override the spam blacklist, I found that the exact same concept had already been proposed back in March 2012, though apparently it never got past the proposal stage, as the permission doesn't exist anywhere on any sites that use MediaWiki. If the permission were to exist on Fandom, it would be redundant for Staff, Wiki Representatives, Wiki Specialists, Helpers, and SOAP members, as they already have the Phalanxexempt permission which implicitly allows them to override the spam blacklist. But since Deluxe Administrators don't have that permission, having the Sboverride permission would be quite handy for them.

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.

Even though it is obvious why Deluxe Administrators have the ability to delete selective revisions from the page history, rather than the entire page history, they 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.

Fandom Staff and Fandom Helpers have the ability to view the spam blacklist via the Phalanx permission. Volunteer Spam Task Force members also had the ability, prior to the usergroup's retirement. Wiki Representatives were subsequently granted the ability in December 2019, and Spam Obliteration and Prevention members were granted it, following their introduction in July 2020. Administrators do not have the ability, because in addition to viewing the spam blacklist, it also allows users to manage global blocks and spam filters. And even then, the ability would be abused too easily and too frequently if Administrators were to have it, since it would allow them to see the blacklist entries and use that knowledge to find ways to get around the spam protection filter.
 * Spamblacklist

Deluxe Administrators were subsequently granted an ability to view the spam blacklist. However unlike the Phalanx permission, the Spamblacklist ability would not allow users to manage global blocks or spam filters. The reason I subsequently decided that Deluxe Administrators should have an ability to view the entries on the spam blacklist was so they would hopefully keep instances of performing actions that would otherwise trigger the spam protection filter to a minimum. Deluxe Administrators can have their rights revoked by Staff if they are found to have abused the privilege of viewing the spam blacklist in order to deliberately do things that would not only have triggered the spam protection filter but is in violation of Fandom's terms of use.

Deluxe Administrators were subsequently granted an ability to view the deleted history entries of all pages, aside from the ones that have been suppressed with the Deleterevision and Suppressrevision permissions. Prior to this wiki's migration to Fandom 's Unified Community Platform in October 2020, users were able to view the deleted history entries of all pages with the Deletedhistory permission, aside from the ones that had been suppressed with the Deleterevision and Suppressrevision permissions.
 * Viewunsuppressed

Since this wiki's migration, users with the Deletedhistory permission have no longer been able to view the deleted history entries of whitelisted system messages without the Editinterface permission, system messages without the Editinterface and Editinterfacetrusted permissions, sitewide CSS without the Editinterface, Editsitecss, and Editinterfacetrusted permissions, sitewide JavaScript without the Editinterface, Editsitejs, and Editinterfacetrusted permissions, or sitewide JavaScript Object Notation without the Editinterface, Editsitejson, and Editinterfacetrusted permissions.

They are also no longer able to view the deleted history entries of one's own CSS files without the Editmyusercss or Editusercss permissions, one's own JavaScript files without the Editmyuserjs or Edituserjs permissions, one's own JavaScript Object Notation files without the Editmyuserjson or Edituserjson permissions, other users' CSS files without the Editusercss permission, other users' JavaScript files without the Edituserjs permission, other users' JavaScript Object Notation files without the Edituserjson permission, without the Editinterface, Editsitecss, and Edit-fandommobile-customizations permissions, or  without the Editinterface, Editsitejs, and Edit-fandommobile-customizations permissions.

Deluxe Administrators were granted the fictional ability that allows them to view the deleted history entries of all pages, aside from the ones that have been suppressed, in case they ever run into any unsuppressed deleted history entries that they are unable to view. However since Deluxe Administrators already have the Editinterface, Editsitecss, Editsitejs, Editsitejson, Editinterfacetrusted, Editusercss, Edituserjs, Edituserjson, and Edit-fandommobile-customizations permissions as well as the Deletedhistory permission, the chances of them not being able to view any unsuppressed deleted history entries are very small.

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

Deluxe Administrators were subsequently granted the ability to add and remove Comment Control rights from other users, after it was decided that they should be able to grant and revoke any fictional local usergroup permissions below Junior Admin.
 * Comment Controllers

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

Deluxe Administrators were subsequently granted the ability to add and remove Image Control rights from other users, after it was decided that they should be able to grant and revoke any fictional local usergroup permissions below Junior Admin.
 * Image Controllers

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

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.

Deluxe Administrators were subsequently granted the ability to add and remove Junior Admin rights from their own account, after it was decided that they should be able to grant and revoke any fictional local administrative usergroup permissions from their own account that are below Bureaucrat.
 * Junior Admins

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. They are also able to approve local sitewide JavaScript that has been submitted for review and is deemed safe, and reject JavaScript that is deemed unsafe.

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. Deluxe Administrators shouldn't approve unreviewed JavaScript that is deemed unsafe, or JavaScript that they are unsure about. They shouldn't insert content that would otherwise have triggered the spam protection filter, or 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.

System Messages associated with the usergroup
Listed below are the system messages associated with the Deluxe Administrator usergroup.