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 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 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 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 Staff, Fandom Helpers, and Spam Obliteration and Prevention members have the ability to view social logs. Global Discussion Moderators were subsequently granted the ability to view social logs in June 2021. Wiki Representatives were also granted the ability, following their introduction in July 2021. Wiki Managers and Volunteer Spam Task Force members also had the ability, prior to their respective retirements.
 * Discussionslog : view

Wiki Specialists were subsequently granted the ability in December 2021. User Rollbackers were subsequently granted the ability to view social logs in June 2021, so they would be able to lessen the chances of reverting global spam or vandalism made by users whose IP addresses had already been reported on the SOAP Wiki. User Rollbackers were forbidden to use their social log access rights for any other reason, including check user requests.

User Rollbackers lost the ability to view social logs in April 2022, as the system messages associated with the Discussionslog:view permission on Fandom wikis that use MediaWiki 1.37.2 are associated with the Sociallogs permission instead. This implies that the Discussionslog:view permission will be removed and its abilities will be transferred to the Sociallogs permission in the near future. Therefore User Rollbackers won't be able to continue accessing the Special:SocialLogs page via the Discussionslog:view permission when that time comes.

Fandom Staff and Fandom Helpers previously had the ability to view the discussions log. Wiki Representatives and Spam Obliteration and Prevention members were also granted the ability, following their respective introductions in July 2021 and July 2020. Global Discussion Moderators were subsequently granted the ability to view the discussions log in May 2021.
 * Specialdiscussionslog

Wiki Managers and Volunteer Spam Task Force members also had the ability, prior to their respective retirements. Wiki Specialists were subsequently granted the ability in December 2021. User Rollbackers were subsequently granted the ability to view the discussions log in June 2021, so they would be able to lessen the chances of reverting global spam or vandalism made by users whose IP addresses had already been reported on the SOAP Wiki. User Rollbackers were forbidden to use their discussions log access rights for any other reason, including check user requests.

User Rollbackers lost the ability to view the discussions log in March 2022, after the ability was removed and fully replaced with the Discussionslog:view permission. Fandom Staff, Wiki Representatives, Wiki Specialists, Fandom Helpers, Spam Obliteration and Prevention members, and Global Discussion Moderators also lost the ability in March 2022 for that reason.

Fandom Helpers previously had 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. Fandom Helpers, Wiki Representatives, Spam Obliteration and Prevention members lost the ability in December 2021 for that reason.

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, Wiki Specialists, 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 and Bureaucrats 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 Forums:delete, Posts:delete, Posts:deleteall, and Sociallogs 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 a Spam Obliteration and Prevention member, they will have a Spam Obliteration and Prevention member badge next to their avatar instead. If they are also a 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 Wiki Specialist, Wiki Representative, or a member of Fandom Staff, they will have a Fandom Staff badge next to their avatar instead. If they are also a Content Moderator, they will have a Content Moderator 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.

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 Managers and Content Team Members were also granted the ability, following their respective introductions in May and July 2019, prior to their respective retirements. Wiki Representatives and Wiki Specialists were also granted it, following their respective introductions in July 2021.
 * Sboverride

User Rollbackers were subsequently granted an ability to override the spam blacklist in June 2021. However unlike the Phalanxexempt permission, the Sboverride ability would not have made users immune to global blocks. The reason I subsequently decided that User Rollbackers 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 reverting spam and vandalism.

Even though User Rollbackers were subsequently granted an ability to override the spam blacklist, they were expected to take note of the blacklist entries that would otherwise trigger the spam protection filter. They could have had their rights revoked by Staff if they were 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 was in violation of Fandom's terms of use. Although in practice most User Rollbackers would probably also be Staff anyway.

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 User Rollbackers don't have that permission, having the Sboverride permission would be quite handy for them.

User Rollbackers lost the ability on all wikis in July 2021 after it was decided that they shouldn't have any permissions related to the SpamBlacklist extension, as it doesn't appear on Fandom wikis by default. However they do still have the ability to override the spam blacklist on wikis that have the SpamBlacklist extension added to them. User Rollbackers were granted another fictional permission titled Spamfilter-bypass so that they would still be able to override the spam protection filter on wikis that don't have the SpamBlacklist extension added to them.

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 Managers were subsequently granted the ability in December 2019, prior to their retirement. Wiki Representatives and Spam Obliteration and Prevention members were also granted it, following their introductions in July 2021 and July 2020. Wiki Specialists were subsequently granted the ability in December 2021. User Rollbackers were subsequently granted an ability to view the spam blacklist in June 2021. However unlike the Phalanx permission, the Spamblacklist ability would not have allowed users to manage global blocks or spam filters.
 * Spamblacklist

The reason I subsequently decided that User Rollbackers 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 have triggered the spam protection filter to a minimum. User Rollbackers could have had their rights revoked by Staff if they were 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 were in violation of Fandom's terms of use. Although in practice most User Rollbackers would probably also be Staff anyway.

User Rollbackers lost the ability on all wikis in July 2021 after it was decided that they shouldn't have any permissions related to the SpamBlacklist extension, as it doesn't appear on Fandom wikis by default. They do still have the ability to view the spam blacklist on wikis that have the SpamBlacklist extension added to them, but I decided to change the name of the fictitious Spamblacklist permission to Spamblacklistview so that it would be more obvious what the permission did. User Rollbackers were granted another fictional permission titled Spamfilter-view so that they would be able to view the spam protection filter, via the Phalanx special page on wikis that don't have the SpamBlacklist extension added to them.

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.