B: Handle consecutive vandalisms on the same Article. (Solution 1)

[Grahamwp]

Original Subject: WikiLoop Battlefield only partially reverts in cases of consecutive vandalism edits done by the same user

The subject line says it all. I think this is a major issue due to misleading edit summaries, and this project should be disabled until it is fixed. See this page history. I also brought this up on Meta, along with another minor issue.

[xinbenlv]

Hi @Grahamwp thanks for your report of issue. Per your request, I temporily disabled revert until a solution is work out. Let's have follow up discussion about how we can resolve this problem.

You should see the application behavior already changed: when a revision is marked as ShouldRevert, it will not popup the button to a shortcut URL to conduct the actual revert.

[xinbenlv]

Solution 1: When a revision is marked as ShouldRevert, also check if a previous revision is from the same user, if it comes from the same user, instead of going to the revert shortcut link, we let people go to the article history of the title.

1. with revId we have title
2. with title we can make a query to Action API.

{
	"action": "query",
	"format": "json",
	"prop": "revisions",
	"titles": "Wikipedia",
	"rvlimit": "2" # 2 will be good enough, but we can also get 10 or more for further discussion.
}

3. If previous revision is from the same user, we direct people to article history URL instead of the shortcut revert URL

[Grahamwp]

Thanks for disabling the edit functionality for now. What I was thinking was more broadly in line with how other anti-vandalism tools work. Go to the last revision not by the vandal, click on the edit link there (so you're editing that revision), and put in the edit summary something like "Reverting to last version by [name of previous user] ... [program string]". In the Federation of Australia example, you'd go here:
https://en.wikipedia.org/w/index.php?title=Federation_of_Australia&action=edit&oldid=908842179

Ideally this revert would be automated using OAuth or something to establish a user's credentials, for efficiency, like other anti-vandalism tools. Also, ideally the vandalism tool should warn the user using {{subst:uw-vandalism[n]}} ~~~~, where n is from 1 to 4, and then report the user for vandalism at the Administrator intervention against vandalism page after they've received four warnings in a month, again per usual practice.

I think you should really have a go at some anti-vandalism tools yourself and maybe dive into their code to see how they operate. The most popular are both open-source ... Twinkle and, for what I'm told is vandalism-fighting on steroids, Huggle. Their talk pages might help you find other users willing to advise you. I've actually never done RecentChanges patrolling in my life (I have enough problems with my watchlist!), and my only modern programming experience is enough Python to be dangerous. I've just been on Wikipedia for a really, really long time and have experienced a lot of things on the site.

[xinbenlv]

This is fixed by 0e5c6ec commit.
We render the solution 1 for now.

We are going to create a second solution that more integrated with MediaWiki, but will require #61

[xinbenlv]

Close for Solution 1. For Solution 2 that involves comprehensive login-integration and permission application, we will do it in a separate Feature Request: #65