User Rollbackers/Removed

This is a list of usergroup rights that were previously extended to the fictional User Rollback usergroup that was conceived by C.Syde in March 2016. For information about the usergroup rights that are currently extended to this fictional global usergroup, see this page.

Abilities that User Rollbackers previously had
Since the User Rollback usergroup is based around the userrollback extension, it isn't supposed to have many abilities as a standalone group. Most of the abilities that were previously included in the User Rollback usergroup were removed after it was decided that they weren't relevant to the User Rollback usergroup, they allowed them to do things or bypass restrictions that they weren't intended to be able to do or be able to bypass, or they allowed User Rollbackers to do things or bypass restrictions on local wikis that went against the best wishes of their communities.

User Rollbackers were subsequently given the ability to bypass IP-based rate limits, in case their account was less than 4 days old. However they lost the ability in September 2017, after it was decided that being able to bypass IP-based rate limits was irrelevant to User Rollbackers.
 * Autoconfirmed

Since the odds of User Rollback rights being granted to an account that was less than 4 days old were very small. And even if such odds did happen, User Rollbackers would still have been able to revert the vandalism with the userrollback extension. Userrollback works on the server side, so there's no notification of 'user permissions', as the extension has direct access to the database.

Because the extension has direct access to the database, users with the Userrollback permission would have been able to use it to revert vandalism across semi-protected pages, regardless if they didn't have the Autoconfirmed permission. Otherwise they would still have been able to temporarily flag themselves as a Content Moderator or Assistant during that time, should they have been unable to revert vandalism on a semi-protected page.

User Rollbackers were subsequently given the ability to bypass CAPTCHAs, in case their account was less than 4 days old. However they lost the ability in September 2017, after it was decided that being able to bypass CAPTCHAs was irrelevant to User Rollbackers.
 * Skipcaptcha

Since the odds of User Rollback rights being granted to an account that didn't have a verified email address were very small. And even if such odds did happen, User Rollbackers would still have been able to revert the vandalism with the userrollback extension. Userrollback works on the server side, so there's no notification of 'user permissions', as the extension has direct access to the database.

Because the extension has direct access to the database, users with the Userrollback permission would have been able to use it to revert vandalism across articles, regardless if they didn't have the Skipcaptcha permission. Otherwise they would still have been able to temporarily flag themselves as an Assistant during that time, should they have ever needed to bypass a CAPTCHA. Otherwise they could simply check the confirmation box.

User Rollbackers were subsequently granted the ability to delete comments from blog articles. However they lost the ability in September 2020, in preparation for what would become the retirement of the article comments feature, once all wikis were migrated over to Fandom 's Unified Community Platform.
 * Blog-comments-delete

Unlike local Administrators and Discussion Moderators, User Rollbackers were almost never permitted to use their delete tools. User Rollbackers were granted the ability to delete blog comments in case they ever failed to successfully delete the blog comments with the Userrollback extension.

Userrollback works on the server side, so there's no notification of 'user permissions', as the extension has direct access to the database. But User Rollbackers still had the Blog-comments-delete permission, in case they ever needed it. Despite previously having the ability to delete blog comments, User Rollbackers were only permitted to delete blog comments if for some reason they ran into anything that the Userrollback extension was unable to revert and delete.

User Rollbackers were subsequently granted the ability to delete article comments. However they lost the ability in March 2020, in preparation for what would become the retirement of the article comments feature, once all wikis were migrated over to Fandom 's Unified Community Platform.
 * Commentdelete

Unlike local Administrators, Content Moderators, and Discussion Moderators, User Rollbackers were almost never permitted to use their delete tools. User Rollbackers were granted the ability to delete article comments in case they ever failed to successfully delete article comments with the Userrollback extension.

Userrollback works on the server side, so there's no notification of 'user permissions', as the extension has direct access to the database. But User Rollbackers still had the Commentdelete permission, in case they ever needed it. Despite previously having the ability to delete article comments, User Rollbackers were only permitted to delete article comments if for some reason they ran into anything that the Userrollback extension was unable to revert and delete.

User Rollbackers were subsequently granted the ability to remove message wall messages. However they lost the ability in March 2020, in preparation for what would become the retirement of the message wall feature, once all wikis were migrated over to Fandom 's Unified Community Platform.
 * Wallremove

Unlike local Administrators and Discussion Moderators, User Rollbackers were almost never permitted to use their message wall remove tools. User Rollbackers were granted the ability to remove message wall messages in case they ever failed to successfully delete the message wall messages with the Userrollback extension.

Userrollback works on the server side, so there's no notification of 'user permissions', as the extension has direct access to the database. But User Rollbackers still had the Wallremove permission, in case they ever needed it.

Despite previously having the ability to remove message wall messages, User Rollbackers were only permitted to remove message wall messages if for some reason they ran into anything that the Userrollback extension was unable to revert and delete, and they found themselves unable to delete a message wall message without removing it first.

User Rollbackers were subsequently given the ability to use higher limits in API queries. However they lost the ability in May 2017, after it was decided that being able to use higher limits in API queries was irrelevant to User Rollbackers. And even if it were relevant, User Rollbackers would still have been able to temporarily flag themselves as an Assistant during that time, should they have ever needed to use higher limits in API queries.
 * Apihighlimits

User Rollbackers were subsequently given the ability to override the disallowed title or username list. However they lost the ability in May 2017, after it was decided that being able to override the disallowed title or username list was irrelevant to User Rollbackers. And even if it were relevant, User Rollbackers would still have been able to override the disallowed title or username list when using the userrollback extension.
 * Tboverride

Userrollback works on the server side, so there's no notification of 'user permissions', as the extension has direct access to the database. Because the extension has direct access to the database, users with the Userrollback permission would have been able to use it to revert vandalism across articles, regardless if they didn't have the Tboverride permission. Otherwise they would still have been able to temporarily flag themselves as an Assistant during that time, should they have ever needed to override the disallowed title or username list.

User Rollbackers were subsequently given the ability to delete all MediaWiki messages. However, unlike local Administrators, User Rollbackers were actually almost never permitted to delete MediaWiki messages. User Rollbackers were granted the ability to delete all MediaWiki messages in case they were unable to delete MediaWiki messages that had been created by a cross-wiki spammer or vandal on a wiki where they had Administrator rights, and none of their global contributions consisted of anything other than spam and vandalism. They were also granted the ability to delete MediaWiki messages in case they ever failed to successfully delete MediaWiki messages with the Userrollback extension.
 * Deleteinterfacetrusted

Despite having the ability to delete all MediaWiki messages at one point, User Rollbackers were only permitted to delete MediaWiki messages if for some reason they ran into any messages that the Userrollback extension was unable to revert and delete. User Rollbackers lost the ability to delete MediaWiki messages in July 2018, shortly after they were granted the ability, after it was decided that User Rollbackers shouldn't have the ability to delete all MediaWiki messages if they didn't have the ability to edit MediaWiki messages.

This was also done to counter the possibility of User Rollbackers deleting MediaWiki messages with the delete button on wikis where they had Content Moderator, but not Administrator rights. However removing the Deleteinterfacetrusted permission from User Rollbackers didn't serve as much purpose as it had been intended to, as User Rollbackers can still revert and delete spam and vandalism with the userrollback extension, even if it involves reverting edits across MediaWiki pages or deleting them.

Userrollback works on the server side, so there's no notification of 'user permissions', as the extension has direct access to the database. Because the extension has direct access to the database, users with the Userrollback permission would have been able to use it to revert and delete spam and vandalism from specific users across all wikis, regardless if they didn't have the Deleteinterfacetrusted permission. As it turns out, User Rollbackers wouldn't have been able to use the Deleteinterfacetrusted permission without the Editinterface permission.

User Rollbackers previously had the ability to bypass autoblocks, IP-blocks, and range blocks. However they lost the ability in July 2018, after it was decided that User Rollbackers shouldn't be able to bypass autoblocks, IP-blocks, and range blocks.
 * Ipblock-exempt

Seeing as User Rollbackers didn't have the ability to block users from editing, or the ability to manage global blocks and spam filters. Being able to bypass autoblocks, IP-blocks, and range blocks was highly irrelevant to User Rollbackers in any case, as they would still have been able to bypass autoblocks, IP-blocks, and range blocks when using the userrollback extension.

Userrollback works on the server side, so there's no notification of 'user permissions', as the extension has direct access to the database. Because the extension has direct access to the database, users with the Userrollback permission would have been able to use it to bypass autoblocks, IP-blocks, and range blocks, regardless of what permissions they had.

User Rollbackers were subsequently granted the ability to delete message wall messages. However they lost the ability in March 2020, in preparation for what would become the retirement of the message wall feature, once all wikis were migrated over to Fandom 's Unified Community Platform.
 * Walladmindelete

Unlike local Administrators, User Rollbackers were almost never permitted to use their message wall delete tools. User Rollbackers were granted the ability to delete message wall messages in case they ever failed to successfully delete the message wall messages with the Userrollback extension.

Userrollback works on the server side, so there's no notification of 'user permissions', as the extension has direct access to the database. But User Rollbackers still had the Walladmindelete permission, in case they ever needed it. Despite previously having the ability to delete message wall messages, User Rollbackers were only permitted to delete message wall messages if for some reason they ran into anything that the Userrollback extension was unable to revert and delete.

Fandom Helpers have the ability to be exempted from first edit dialogues when editing on a wiki for the first time. Wiki Representatives and Spam Obliteration and Prevention members were also granted the ability to be exempted from first edit dialogues, following their respective introductions in July 2021 and July 2020. Wiki Managers were also granted the ability, following their introduction in May 2019 until their retirement.
 * First-edit-dialog-exempt

Global Bots, Fandom Utilities, Fandom Staff, and Vanguards also had the ability to be exempted from first edit dialogues, prior to this wiki's migration to Fandom 's Unified Community Platform. Volunteer Spam Task Force members also had the ability to be exempted from first edit dialogues, prior to the usergroup's retirement.

User Rollbackers were subsequently granted the ability to be exempted from first edit dialogues in October 2020, since I imagined that it would be pretty annoying for them to have to constantly put up with first edit dialogues when reverting vandalism from wikis that they previously haven't edited on. However they lost the ability in March 2021, as the permission apparently no longer works on Fandom wikis. This may explain why Global Bots, Utilities, Staff, and Vanguards lost the ability upon this wiki's migration and have regained it since.

User Rollbackers were subsequently given the ability to bypass phalanx rules, so that they would be unaffected by the spam protection filter. However they lost the ability to bypass phalanx rules in April 2017, because it was decided that User Rollbackers shouldn't be immune to global blocks.
 * Phalanxexempt

When I decided that User Rollbackers should be exempt from phalanx rules, I was unaware that they would be immune to global blocks as well. And since User Rollbackers cannot manage local blocks or global blocks, I decided that they shouldn't be immune to either of them.

Currently the only usergroups that are exempt from phalanx rules are Fandom Staff, Wiki Representatives, Wiki Specialists, Fandom Helpers, and Spam Obliteration and Prevention members. Wiki Managers, Content Team Members, and Volunteer Spam Task Force members were also exempt from phalanx rules, prior to the usergroups' respective retirements.

All of these usergroups have the ability to block users locally, as well as Fandom Staff, Wiki Representatives, Fandom Helpers, and Spam Obliteration and Prevention members having the ability to manage global blocks and spam filters.

Being able to bypass phalanx rules was highly irrelevant to User Rollbackers in any case, as they would still have been able to bypass phalanx rules when using the userrollback extension. Userrollback works on the server side, so there's no notification of 'user permissions', as the extension has direct access to the database.

Because the extension has direct access to the database, users with the Userrollback permission would have been able to use it to bypass phalanx rules, regardless of what permissions they had.

User Rollbackers previously had the Unblockable permission which prevented them from getting blocked by Administrators on local communities. The reason User Rollbackers had this permission was so that they could revert global spam and vandalism without getting blocked on any wikis they were trying to revert global spam and vandalism on.
 * Unblockable

Even though they previously had the Unblockable permission, if any users had already been locally blocked on a community, prior to receiving User Rollback rights, they wouldn't have been able to unblock themselves, as they do not have the permission to remove any blocks placed upon their account. This is also the case with members of the Spam Obliteration and Prevention. It was also the case with members of the Volunteer Spam Task Force, prior to the usergroup's retirement.

Fandom Staff, Wiki Representatives, Wiki Specialists, and Fandom Helpers have the Unblockself permission, so if they had been locally blocked on a wiki, prior to receiving Staff, Wiki Representative, Wiki Specialist, or Helper rights, they would be able to unblock themselves. This was also the case with Wiki Managers and Content Team Members, prior to their respective retirements.

User Rollbackers lost the Unblockable permission in August 2017, after it was decided that User Rollbackers shouldn't have the Unblockable permission if they couldn't block users locally or globally. This was also done out of respect for local communities in case they didn't want certain User Rollbackers to revert any spam or vandalism there. However removing the Unblockable permission from User Rollbackers didn't serve as much purpose as it had been intended to, as User Rollbackers can still revert and delete spam and vandalism with the userrollback extension.

Userrollback works on the server side, so there's no notification of 'user permissions', as the extension has direct access to the database. Because the extension has direct access to the database, users with the Userrollback permission would have been able to use it to revert and delete spam and vandalism from specific users across all wikis, regardless if they were blocked on any of them.

User Rollbackers previously had the ability to bypass automatic blocks of proxies. However they lost the ability in December 2016, after it was decided that User Rollbackers shouldn't be able to bypass automatic blocks of proxies. Seeing as User Rollbackers didn't have the ability to block users from editing, or the ability to manage global blocks and spam filters.
 * Proxyunbannable

On top of that, at the time of the fictional usergroup's creation, I imagined User Rollbackers as being like Global Rollbackers, but in Volunteer Spam Task Force form. Since VSTF didn't have the ability to bypass automatic blocks of proxies, prior to the usergroup's retirement, I felt that it was unnecessary for User Rollbackers to have it. Being able to bypass automatic blocks of proxies was highly irrelevant to User Rollbackers in any case, as they would still have been able to bypass automatic blocks of proxies when using the userrollback extension.

Userrollback works on the server side, so there's no notification of 'user permissions', as the extension has direct access to the database. Because the extension has direct access to the database, users with the Userrollback permission would have been able to use it to bypass automatic blocks of proxies, regardless of what permissions they had.

User Rollbackers were subsequently granted the ability to have their User Rollback badge appear next to their avatars in in October 2020. Though Fandom Staff, Fandom Helpers, Global Discussion Moderators, Administrators, and Discussion Moderators have badges appearing next to their avatars in Discussions, their corresponding badge permissions don't display in Special:ListGroupRights. However certain GitHub repositories imply that such badge permissions did exist for a short period of time.
 * Badge : userrollback

Volunteer Spam Task Force members also had badges appearing next to their avatars in Discussions, prior to the usergroup's retirement. User Rollbackers were granted the ability to have their User Rollback badge appear next to their avatars so that they could be distinguished from users that did not have any Discussions related permissions. However User Rollbackers don't have any additional permissions in Discussions aside from the Discussionslog:view, Forums:delete, Posts:delete, Posts:deleteall, and Specialdiscussionslog rights, so one could argue that User Rollbackers having their own badges in Discussions is largely unnecessary.

And in any case if a User Rollbacker is also Global Discussion Moderator, they will have a Global Discussion Moderator badge next to their avatar instead. If they are also a Fandom Helper, they will have a Fandom Helper badge next to their avatar instead. If they are also a member of Fandom Staff, they will have a Fandom Staff badge next to their avatar instead. If they are also a Discussion Moderator, they will have a Discussion Moderator badge next to their avatar instead. If they are also an Administrator, they will have an Administrator badge next to their avatar instead.

User Rollbackers lost the ability to have their User Rollback badge appear next to their avatars in Discussions shortly after they were granted the ability, because the badge permissions were scrapped shortly before the remaining Discussions related permissions were added to the Special:ListGroupRights page. Since the code relating to Discussions supports showing the badges in Discussions without the said permissions appearing on the Special:ListGroupRights page, all usergroups including User Rollbackers with Discussions badges implicitly have them anyway.

Groups that User Rollbackers were previously able to add or remove from other accounts
User Rollbackers were previously able to grant and revoke Rollback rights from other users on local communities. However, unlike local Bureaucrats and Administrators, User Rollbackers were actually almost never permitted to add or remove Rollback rights from other users.
 * Rollbackers

User Rollbackers lost the ability to add and remove Rollback rights from other accounts on local communities in July 2017, after it was decided that User Rollbackers shouldn't be able to modify the user rights of other users on local communities.

This was also because Volunteer Spam Task Force members had recently lost the ability to add and remove Rollback and Bot rights from other accounts on local communities, and because the time of the fictional usergroup's creation, I imagined User Rollbackers as being like Global Rollbackers, but in VSTF form.

Groups that User Rollbackers were previously able to add or remove from their own account
User Rollbackers were previously able to add and remove Assistant rights to and from their own account on C.Syde's Wiki and the Encyclopedia SpongeBobia. However, unlike local Bureaucrats and Administrators, User Rollbackers were actually almost never permitted to add Assistant rights to their own account. User Rollbackers had the ability to add Assistant rights to their own account, in case they ever ran into a situation where they were unable to fully revert global spam or vandalism by specific users using their User Rollback rights.
 * Assistants

User Rollbackers lost the ability to add and remove Assistant rights to and from their own account on C.Syde's Wiki and the Encyclopedia SpongeBobia in December 2018, after it was discovered that User Rollbackers didn't need to belong to any other usergroups or have any extra permissions in order to use the Userrollback extension effectively. Userrollback works on the server side, so there's no notification of 'user permissions', as the extension has direct access to the database.

Because the extension has direct access to the database, users with the Userrollback permission would have been able to use it to quickly revert cross-wiki spam and vandalism from specific users across all wikis, regardless if they didn't have the Editsemiprotected permission in order to revert edits made on semi-protected pages. And regardless if they didn't have the Editprotected permission in order to revert edits made on fully protected pages.

User Rollbackers were previously able to add and remove Content Moderator rights to and from their own account on local communities. However, unlike local Bureaucrats and Administrators, User Rollbackers were actually almost never permitted to add Content Moderator rights to their own account. User Rollbackers had the ability to add Content Moderator rights to their own account, in case they ever ran into a situation where they were unable to fully revert global spam or vandalism by specific users using their User Rollback rights.
 * Content Moderators

User Rollbackers lost the ability to add and remove Content Moderator rights to and from their own account on local communities in December 2018, after it was discovered that User Rollbackers didn't need to belong to any other usergroups or have any extra permissions in order to use the Userrollback extension effectively. Userrollback works on the server side, so there's no notification of 'user permissions', as the extension has direct access to the database.

Because the extension has direct access to the database, users with the Userrollback permission would have been able to use it to quickly revert and delete cross-wiki spam and vandalism from specific users across all wikis, regardless if they didn't have the Editprotected permission in order to revert edits made on fully protected pages. And regardless if they didn't have the Delete permission in order to delete pages created by cross-wiki spammers and vandals.

User Rollbackers were previously able to add and remove Rollback rights to and from their own account on local communities. However, unlike local Bureaucrats and Administrators, User Rollbackers were actually almost never permitted to add Rollback rights to their own account.
 * Rollbackers

User Rollbackers lost the ability to add and remove Rollback rights to and from their own account on local communities in January 2018, after it was decided that it was pointless for User Rollbackers to have the ability to add Rollback rights to their own account, as they already had all the permissions extended to Rollbackers on all wikis.

Groups that User Rollbackers were previously able to remove from their own account
User Rollbackers were subsequently able to remove User Rollback rights from their own account. However, they lost the ability to remove User Rollback rights from their own account in April 2016, shortly after they were granted it.
 * User Rollbackers

User Rollbackers lost the ability to self-revoke their User Rollback rights after it was decided that fictional global usergroups shouldn't be able to remove global usergroups from their own account, seeing as most of the real global usergroups weren't self-revocable.