Fri, Nov 8
Imo CheckUserTest or CheckUserDev or CheckUserAlpha. I assume when it goes to production (new version enabled in config) it will replace the current CheckUser and this in-development name will be dropped.
Thu, Nov 7
Besides subnet (whois) and geolocation, presenting Proxy/VPN data would be useful for CU. Example: https://www.ipqualityscore.com/free-ip-lookup-proxy-vpn-test/lookup/18.104.22.168
This data is no more reliable than Geoloc data, yet it is a good clue for determining the likelihood of a proxy user.
^^^^ For description.
A more substantive task.
Add 3 columns: Subnet (name and ip range of the subnetwork), Geolocation (closest city, generally), Proxy/VPN (reported open proxies, IPs used for spamming)
This would greatly increase the efficiency of recognizing IPs from around the world (VPN users), dynamic ips on the same subnet, open proxies/free VPNs, etc.
I'd add a minor feature - a "Proxy/VPN check" link - after "Tor check" (pull request): <a href="https://www.ipqualityscore.com/free-ip-lookup-proxy-vpn-test/lookup/<?=$IP ?>">Proxy/VPN check</a>
There is a new blank/hello-world special page created by the CheckUser extension, titled CheckUser 2.0 behind a feature flag
@Niharika that's perfect. I've re-parented the leftover tasks in the tree above. Only the Orphans and the Old/stale tasks remain to be reviewed and anything I might have missed in the backlog. There were a few tasks that weren't obvious, so I'll run through the list once more and maybe you might be aware of a task I wasn't.
Wed, Nov 6
I suggest the following tree to separate tasks expected to be done in 2019 (T132892: CheckUser UI revamp are tasks from 2016)
A hub/parent task with 10 subtasks:
T132892: CheckUser UI revamp
Oct 13 2019
Oct 8 2019
Oct 7 2019
Oct 6 2019
I haven't seen any information about the design / implementation of this system, so I've drafted a proposed workflow from creating a report all the way to decision making, in a process similar to an ArbCom case, that's applicable to simple, everyday reports as well.
Oct 4 2019
Thank you to the devs for this update. Revision info is more noticeable now, while before I often missed it.
Sep 20 2019
The motivation for this feature was to keep the private email address hidden, when sending email on-wiki. This can be achieved with an alternative solution that is simpler for the user, but might complicate configuring the server a bit.
A common solution to this problem is to give a wiki email address to users (such as email@example.com), and forward/proxy emails to the private address.
Emails sent on-wiki have the header field From: firstname.lastname@example.org
Replies (and any email) sent to email@example.com are only accepted from confirmed user email addresses (SPF / DKIM fields checked). This identifies the sender's username2 account.
The body of the email and a few header fields (Subject, Date, Content-Type, Content-Transfer-Encoding) are sent to the user's private address with Sender: firstname.lastname@example.org
As a result editors only see the username of the sender. It's up to the editors to share their private email address, if they choose to.
"en.wikipedia.org" can be any wiki instance.