SelectiveDelete

SelectiveDelete (previously known as MultipleRevisionDelete or MultiRevisionDelete) is a fictional user ability that allows users with the ability to delete pages to selectively delete revisions from the page history. It is basically the same as deleting a page and then restoring the selective revisions. Except that the article doesn't show up as deleted during the process.

Inspiration
Even though such an ability does not exist anywhere on Fandom, or indeed on any site to my knowledge, it has remained to be the one nonexistent feature that I have always wanted to be existent. Ever since I discovered that Administrators were unable to delete selective revisions. They could only restore selective revisions. Ever since Administrators lost the ability to restore CSS  and  JavaScript  pages, and messages with the Custom-٭, Editnotice-٭, Gadget-٭, Gadgets-٭, and Tag-٭ prefixes in August 2015, my desire for such an ability to delete selective revisions grew stronger.

This is because I often liked to keep a tidy CSS page history where only the revisions that were necessary to keep track of were left on the surface. So I basically felt defeated, knowing that I would not be able to delete the revisions that were unnecessary, as I would have to delete all the revisions that I didn't want to delete as well.

I actually once requested the already existent (deleterevision) permission in October 2017 for Administrators 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), (undelete), and (deleterevision) 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 saying that the ability was related to Manual:RevisionDelete, which was intentionally only used to deal with major legal and TOU concerns. And since Staff wanted to keep its use limited, it wasn't something that they typically granted to communities on request. Had I understood what the tool actually did, I would no doubt have refrained from requesting it.

User Groups intended to have the ability
As I mentioned above, there are no usergroups on Fandom that have an ability exactly like SelectiveDelete. But if the ability actually existed on Fandom, I would imagine that Administrators would be the only local usergroup that would be permitted to have that ability. In fact I can't even Administrators having the ability at all by default. However I can imagine that it could be granted to Administrators on request. Since SelectiveDelete could be abused very easily, I can't really imagine communities being granted the ability unless they had a good reason for it. Similar to Bureaucrats being granted the ability to flag accounts as Bots, it's not an ability that I can see Fandom Staff typically granting to communities just because they request to have it. I can only imagine it being granted on larger communities where constant vandalism occurs.

In some cases, it may be that Staff would instead grant SelectiveDelete to Bureaucrats on request, rather than Administrators. Since it would be a tool that could be abused very easily, it is likely that Staff would only entrust Bureaucrats with the ability, or else add a custom usergroup to the said wiki with that permission, and only granting it to a couple of the users on the wiki that had Administrator or Bureaucrat rights.

The global usergroups I imagined it being granted to were Fandom Staff, Wiki Representatives, Wiki Specialists, and Fandom Helpers. The only reason I didn't imagine it being granted to Spam Obliteration and Prevention members is because they already had the RevisionDelete permission. Though this imagining of mine backfired when the RevisionDelete permission was transferred from Fandom Utilities to Fandom Staff, Wiki Managers, and Fandom Helpers.

When should SelectiveDelete be used?
SelectiveDelete should be used 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 would violate Fandom 's terms of use.

It would also be encouraged for an Administrators to delete revisions from page histories in situations that would normally be handled through deleting a page and then immediately restoring the selective revisions. Well SelectiveDelete would allow Administrators to delete the bad revisions, rather than delete the page and then restore the good revisions.

When should SelectiveDelete not be used?
SelectiveDelete should not be used by Administrators to settle editing disputes; for example, remove revisions from histories made by a specific editor, in order to settle an editing dispute that isn't vandalism. It isn't something that should be used to settle simple disagreements between users that are acting in good faith.

SelectiveDelete should really only be used to delete revisions that are obvious vandalism, and even then it shouldn't normally be used unless an Administrator has a very good reason, such as deleting revisions from the page history containing information - personal or otherwise - that is too sensitive for non-administrators to stumble across.

Similarities and Differences to Special:Undelete
SelectiveDelete would bear many similarities to Special:Undelete, except that it would do the exact opposite of what Special:Undelete did. Undelete allows users to restore entire page histories or restore selective revisions of pages that have been deleted. Whereas SelectiveDelete would serve as an extension to the ability to delete pages. In addition to deleting entire page histories, users with the ability would also be able to delete selective revisions of pages. When a user deletes a page and restores a selection of revisions of that page, the number of revisions restored is automatically added to the page summary, so that the restore page summary looks like this:


 * 08:20, 16 November 2015 C.Syde65  (talk | contribs | block) restored page User talk:C.Syde65 (1 revision restored: Restoring good faith edit.)

When a user uses SelectiveDelete to delete a selection of revisions from that page, the number of revisions deleted would automatically added to the page summary, so that the delete page summary would look like this:


 * 04:39, 25 June 2015 C.Syde65  (talk | contribs | block) deleted page User talk:C.Syde65 (36 revisions deleted: Deleting specific revisions.) ( view/restore )

Unlike Special:Undelete which has its own special page, SelectiveDelete would appear whenever a user hit the delete button in the page's dropdown menu, adding ?action=delete to the URL, but only for users that would have the permission to delete a selection of revisions from the page's history. Otherwise they would just see the delete page normally, without the extra options added with SelectiveDelete. In other words, SelectiveDelete would be built on the same parts of the software as Delete.

Similar to Special:Undelete, SelectiveDelete cannot be performed if it will result in the current revision of a page or file being partially deleted. In such cases, a user will need to check or unhide the newest deleted revision using RevisionDelete, before they can selectively delete all newer revisions of the page.

Similarities and Differences to Special:RevisionDelete
There actually happens to be an extension that is already a feature of the MediaWiki software that runs and Fandom, although there are several differences between it and the fictional SelectiveDelete feature.  (also known as RevDel or RevDelete) is an active extension that can be found on wikis in general. However only Fandom Staff, Wiki Representatives, Fandom Helpers, and Spam Obliteration and Prevention members on Fandom are able to use it. Fandom Utilities were also able to use it, prior to the wiki's migration to the Unified Community Platform. Wiki Managers and Volunteer Spam Task Force members were also able to use it, prior to the usergroup's respective retirements. Despite the similarities of their names, SelectiveDelete and RevisionDelete would be unrelated to one another. All users without the (deleterevision) permission will get a permissions error saying that only Fandom Staff, Wiki Representatives, Fandom Helpers, and Spam Obliteration and Prevention members have access to the page. SelectiveDelete would be similar to RevisionDelete in some ways. Both abilities would allow users to delete revisions from the page history in some form. However SelectiveDelete would be designed to allow users to delete selective revisions from the page history to save the trouble of deleting an entire page and then restore selective revisions. RevisionDelete can focus on more than one revision at a time, but it can't be used to hide the current revision.
 * Deleterevision

SelectiveDelete would only work as an extension to (delete) to allow users to select revisions to delete and do the exact opposite of what (undelete) does. Because it would only be intended for administrative usergroups that already have the (delete) and (undelete) permissions, it would not come with any abilities that can restore pages or revisions. Since the intention was to add to the (delete) permission to make it as advanced as (undelete). RevisionDelete on the other hand has its own special page, unlike SelectiveDelete which would serve as an extension to (delete). It is used 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. Once a revision is hidden, users without the (deletedhistory) and (deletedtext) permissions cannot view them, and users without the (deleterevision) permission cannot restore them.

SelectiveDelete would not be able to be used to hide the contents of specific revisions, the edit summaries of the revisions, or the names of the users/IP addresses that made the edits from users without (selectivedelete). It can only be used to delete selective revisions from pages so users without the (deletedhistory) and (deletedtext) permissions cannot view them, and users without the (deletedhistory) and (undelete) permissions cannot restore them.

The checkboxes that would come with the SelectiveDelete permission would appear whenever a user hit the delete button in the page's dropdown menu, adding ?action=delete to the URL, but only for users that would have the permission to delete a selection of revisions from the page's history. Otherwise they would just see the delete page normally, without the extra options added with SelectiveDelete.

Whereas with RevisionDelete, the checkboxes appear whenever a user hits the history button in the page's dropdown menu, but only for users that have the permission 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.

SelectiveDelete would not be able to delete a selection of revisions from pages with large histories. So in order for it to be used to delete selective revisions from pages with large histories, the user would need to have the (bigdelete) permission. RevisionDelete is completely separate from the page deletion system, and does not require the (bigdelete) permission to hide revisions from pages with large histories.

A problem with SelectiveDelete would be there being no way to prevent prior edits appearing as another user's edit, since SelectiveDelete cannot be used to partially delete revisions, as it deletes entire revisions, moving them from the revision table to the archive table.

RevisionDelete does not cause prior edits to appear as another user's edit, so attribution and history may be less affected. Therefore, SelectiveDelete shouldn't be used to delete revisions that have added any constructive material that wasn't immediately changed or removed in later edits. If this is the case, then RevisionDelete should be used instead of SelectiveDelete.

Another issue with SelectiveDelete would be non-administrators being unable to see which revisions were deleted, since the SelectiveDelete summary is just an altered version of the Undelete summary, saying the number of the revisions that were deleted, but not saying which revisions of that number were deleted.

While RevisionDelete doesn't say which revisions were hidden, it doesn't move the deleted revisions from the revision table to the archive table, so non-administrators would still be able to see which revisions were deleted.

There is another part of the RevisionDelete extension, although only Fandom Staff and Fandom Helpers are able to able to use it. Fandom Utilities were also able to use it, prior to the wiki's migration to the Unified Community Platform. Suppressrevision allows users to suppress the data 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. Once a revision is suppressed, users without the (deletedhistory), (deletedtext), and (suppressrevision) permissions cannot view them, and users without the (deleterevision) and (suppressrevision) permissions cannot restore them.
 * Suppressrevision

SelectiveDelete would be similar to Suppressrevision in some ways. Both abilities would allow users to delete revisions from the page history in some form. However SelectiveDelete would be designed to allow users to delete selective revisions from the page history to save the trouble of deleting a page and then restore the selective revisions. Suppressrevision can focus on more than one revision at a time, but it can't be used to suppress the current revision. SelectiveDelete would only work as an extension to (delete) to allow users to select revisions to delete and do the exact opposite of what (undelete) does. Because it would only be intended for administrative usergroups that already have the (delete) and (undelete) permissions, it would not come with any abilities that can restore pages or revisions. Since the intention was to add to the (delete) permission to make it as advanced as (undelete).

Suppressrevision on the other hand only works as an extension to (deleterevision), unlike SelectiveDelete which would serve as an extension to (delete). RevisionDelete only crosses out 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. Once a revision is crossed out, users without the (deletedhistory) and (deletedtext) permissions cannot view them, and users without the (deleterevision) permission cannot restore them.

SelectiveDelete can delete selective revisions from the page history so that they don't show up in the page history, unlike RevisionDelete which prevents the contents of the revisions from being seen, but doesn't actually remove them from the page history. Suppressrevision does the same thing, but it crosses out 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, so that users without the (deleterevision) and (suppressrevision) permissions cannot restore them.

SelectiveDelete only deletes individual or multiple revisions from pages so users without the (deletedhistory) and (deletedtext) permissions cannot view them, and users without the (deletedhistory) and (undelete) permissions cannot restore them. Suppressrevision on the other hand can suppress data from all users that don't have the (suppressrevision) permission, so that they can't see the data, let alone restore it. Even users that have the (deletedhistory) and (deletedtext) permissions but don't have the (suppressrevision) permission cannot see information that has been removed with the (suppressrevision) permission. While users that have the (deleterevision) permission but not the (suppressrevision) permission cannot restore information that has been removed with the (suppressrevision) permission.

SelectiveDelete would not be able to delete a selection of revisions from pages with large histories. So in order for it to be used to delete selective revisions from pages with large histories, the user would need to have the (bigdelete) permission. Suppressrevision is completely separate from the page deletion system, and does not require the (bigdelete) permission to suppress data from pages with large histories.

A problem with SelectiveDelete would be there being no way to prevent prior edits appearing as another user's edit, since SelectiveDelete cannot be used to partially delete revisions, as it deletes entire revisions, moving them from the revision table to the archive table. Suppressrevision does not cause prior edits to appear as another user's edit, so attribution and history may be less affected. Therefore, SelectiveDelete shouldn't be used to delete revisions that have added any constructive material that wasn't immediately changed or removed in later edits.

Suppressrevision is only used to deal with major legal and TOU concerns. Cases involve deleting potentially libellous information, home addresses and telephone numbers, social security numbers, etc. So naturally, the permission is restricted to Fandom Staff and Fandom Helpers only.

System Messages associated with the ability
Because SelectiveDelete would serve as an extension to the ability to delete pages, most of the system messages that would be associated with SelectiveDelete are identical to those that are associated with the (delete) and (undelete) permissions. However there would be several system messages that would come exclusively with the SelectiveDelete extension, if the extension were to exist.

Listed below are the system messages that would be added to the MediaWiki namespace if the SelectiveDelete extension were to be added to the MediaWiki software that runs and Fandom. Note that all of these system messages are fictional and should not be treated as being part of the MediaWiki software.

The system message is derived from the  system message. The system message is derived from the  system message. The system message is derived from the  system message. The system message is derived from the  system message. The system message is derived from the  system message.

The system message is derived from and identical to the  system message. The system message is derived from and identical to the  system message. The system message is derived from the  system message. The system message is derived from the  system message. The system message is derived from the  system message.

The system message is derived from the  system message. The system message is derived from the  system message. The system message is derived from and identical to the  system message. The system message is derived from the  system message. The system message is derived from the  system message. And the system message is derived from the  system message.