[14:01:42] @CVT @Stewards https://meta.miraheze.org/w/index.php?title=Meta:Administrators%27%20noticeboard&diff=prev&oldid=112787#Reporting_a_cross-wiki_troll https://rottenwebsites.miraheze.org/wiki/Special:Contributions/Autisticide Can anyone check it/lock, please? [14:01:43] [ Difference between revisions of "Meta:Administrators' noticeboard" - Miraheze Meta ] - meta.miraheze.org [14:01:44] [ User contributions for Autisticide - Rotten Websites Wiki ] - rottenwebsites.miraheze.org [14:01:51] Reception123: ^ [14:24:50] looking [14:26:00] RhinosF1: has already been locked by Void [14:26:07] Reception123: yep [17:18:24] @Reception123 or @Void: spambot locking time? https://meta.miraheze.org/wiki/Special:AbuseLog?wpSearchUser=&wpSearchPeriodStart=&wpSearchPeriodEnd=&wpSearchTitle=&wpSearchImpact=0&wpSearchAction=any&wpSearchActionTaken=&wpSearchFilter=&wpSearchWiki=metawiki [17:18:24] [ Abuse filter log - Miraheze Meta ] - meta.miraheze.org [17:26:01] Undoubtedly [17:26:15] sets reminder for later [21:50:21] https://meta.miraheze.org/wiki/Special:CentralAuth?target=Faggots ^ Zero contributions; suggest globally locking before they create any edits. They could always request a global rename to something more permissible. [21:50:22] [ Global account information for Faggots - Miraheze Meta ] - meta.miraheze.org [21:53:17] Voidwalker: ^ [21:53:32] You're supossed to be locking things anyway [21:55:25] Can Global Sysops globally lock accounts? Guessing probably not, but might be worth an RfC or community discussion, potentially, at least to allow them to lock accounts for a defined period of time until a steward can rename or lock indefinitely. [21:55:35] They can [21:55:42] Oh, that's good. [21:55:49] I just know void is looking at stuff anyway [21:55:57] ah [21:56:29] yeah, monitoring the login and meta wiki user creation logs is a great way of getting ahead of obvious problems before disruption occurs [21:57:38] Never had my account globally locked, but what's our user experience like if they try to login? Will they be presented with a custom e-mail contact form that goes to stewards and/or cvt? [21:57:43] We need to get an account creation feed going again [21:57:46] Nope [21:58:00] It's extremely unhelpful [21:58:13] > Nope Hrm, that's too bad because we don't have anything like UTRS. [21:58:42] Not sure where that is on the priority list in Phab, but should have something, whether a UTRS-like system or just a contact form. [21:58:53] You can email stewards[at]miraheze.org [21:59:13] Yeah, but they may not know that unless it tells them that when they try and login. [21:59:13] And the lock reason does say that [21:59:24] It doesn't [21:59:42] It used to tell you your login details were incorrect [21:59:48] It says that in the lock warning on their userpage, but does it say that on the user login screen when they try to login? [21:59:53] But they made it slightly more helpful [22:00:07] Ah, k, that's what I thought. Yeah that could be improved somewhat. [22:01:01] I also think we should have some sort of unblock ticket system for when talk page access has been revoked and if someone abuses the ticket system, they can be blocked from that system only for a maximum of, say, 30-90 days. [22:02:16] is why I hate Wikimedia admins that are quick to revoke talk page access I personally see no problem with a blocked user being confined to their talk page for the duration of the block, as long as their commentary is in compliance with the wiki rules. [22:02:26] Distant thoughts exist [22:02:44] Distant thoughts? An extension? [22:04:05] +1 to Void's edit here: https://meta.miraheze.org/w/index.php?title=MediaWiki:Centralauth-admin-status-reasons [22:04:06] [ MediaWiki:Centralauth-admin-status-reasons - Miraheze Meta ] - meta.miraheze.org [22:04:12] I wouldn't say some sort of UTRS-like system is impossible [22:04:26] And we could turn contact page on [22:04:59] I think some sort of email ticketing solution would be a good idea to have, just in general [22:05:31] Yeah, it'd have to be open source; potentially, we could enlist volunteers, who provide limited private information and sign some sort of confidentiality agreement, to handle requests to redact information, merge accounts, libel complaints, and the like. [22:05:33] That's also a plan but there's nothing useful cheap [22:05:48] The amount companies quote would be half our budget [22:06:06] Why not Phab? Create a separate Phabricator system and design the forms in a more user-friendly way. [22:06:31] Does anyone still use SugarCRM? I remember seeing it was open source; we could self host. [22:07:15] but yes the cloud-based ticketing systems are expensive 🙂 [22:07:26] Very [22:07:35] We might be able to self host [22:07:42] * RhinosF1 thinks [22:07:58] our phab currently requires a wiki account, and isn't really engineered towards email ticketing and non-public information (yes it's possible, but it didn't really work for CoCC) [22:08:02] * RhinosF1 wonders whether we should push the tools side of the bots server more [22:08:12] We could either start a separate VPS instance, potentially, or put it on one of the VPSes that isn't over-taxed, like DNS [22:08:25] We could have an open source solution [22:08:37] And maybe get another fosshost vm [22:08:56] Maybe I should natter Reception123 in the morning to deal with the tools side to it [22:08:58] > our phab currently requires a wiki account, and isn't really engineered towards email ticketing and non-public information (yes it's possible, but it didn't really work for CoCC) @Void Ah, okay, true. Yeah, Phab's a bit overly complicated; it's probably not the best. [22:11:16] Darn, looks like Wikimedia pays for OTRS, and it's not open-source. Do they release the UTRS code on GitHub? [22:11:44] UTRS may be too geared for unblock requests; wouldn't handle other requests well, probably. [22:12:05] It is open source and yes [22:13:18] Put it this way, have this conversation with me in a month and it might be more interesting than distant thoughts. [22:14:09] ah, okay [22:14:52] Looked up SugarCRM since I hadn't in awhile...looks like they ended the Community Edition (https://community.sugarcrm.com/community/news/blog/2018/04/06/sugar-community-edition-open-source-project-ends) in 2018, so the source code would be about two years old. Not sure if that's still worth a look or not. [22:14:53] [ Sugar Community Edition open source project ends | SugarCRM Community ] - community.sugarcrm.com [22:16:35] Should make a list of tech/tools somewhere that we want/are interested in so that we can keep track of this kind of stuff [22:17:23] ^ [22:17:59] https://www.opensupports.com Interface looks nice and simple. Doesn't need to be fancy. Probably would use a separate user database, which could be a good thing, but potentially we could setup OAuth to allow someone to create an account on the ticket system using their Miraheze login? [22:17:59] You can file a task on phab.bots.miraheze.wiki as I suppose tools are sort of in scope [22:18:01] [ OpenSupports - Open Source Support Ticket System ] - www.opensupports.com [22:18:11] If mediawiki login works [22:18:18] But i'm off to sleel [22:18:20] Sleep [22:18:34] @Void can create you an account if not [22:18:53] Oh, right. If they're globally locked, @Void, they wouldn't even be able to access [[Special:Preferences]], right? [22:19:36] Oh you meant me @RhinosF1? [22:19:57] I have a Phab account. Oh, nevermind, you mean Phab.bots.miraheze.wiki. Sorry. [22:19:59] Globally locked means no login, yeah [22:20:08] Darn. [22:20:42] Personally, I'd recommend making a "Tech Wishlist" page somewhere on meta (maybe in my userspace for now), and then create phab tasks where and when desired. [22:20:45] It'd have to be a separate login, which would make it more challenging to verify the requesting user on the ticket system is the same user as the Miraheze system. [22:21:11] > Personally, I'd recommend making a "Tech Wishlist" page somewhere on meta (maybe in my userspace for now), and then create phab tasks where and when desired. @Void Okay, sounds good. [22:23:57] Would probably recommend something that they only need to email, and it is put into the ticketing system, and it doesn't look like that's supported by that system (but I'll look in closer later) [22:26:08] yeah, exactly, that'd be ideal, then they can request a password with their e-mail address if they wanted to manage their ticket(s) using the web-based system [22:26:45] Well, ideally, tickets are not public [22:27:36] If you don't have an account on the ticketing system, you shouldn't be able to see any tickets, and you'd just be able to interact with emails. (My ideal system/setup) [22:27:56] Yeah, the ticket would be publicly only for the requesting user [22:28:14] You couldn't see others' tickets [22:28:52] Only Stewards/SysAdmins and, if the community authorized, Customer Service Volunteers would have access to all tickets. [22:29:26] CSVs would be required to sign some sort of confidentiality agreement and provide evidence of their real name and place of residence, at minimum, I think. [22:30:17] We have NDAs, which is what would be required [22:30:40] yeah [22:30:54] The trouble (for now) is figuring out how to build this system into our current architecture and email setup [22:31:04] but, presumably, stewards would have to provide more information, like copies of driver's license, passport, etc. [22:31:21] I'd want to have an idea on how to solve that before installing [22:31:31] Yeah, exactly. [22:31:54] Question: is Special:BlankPage accessible to anonymous, non-logged in users? [22:31:58] No, aside from some of us on the Board of Directors, you only need name and current residence to sign an NDA and gain access [22:32:12] Maybe we could build the linking form into that page. [22:32:17] ah [22:32:22] >Question: is Special:BlankPage accessible to anonymous, non-logged in users? Should just be a matter of having read rights [22:33:41] yeah, ideally we just need to find a way to present the user with a form, sourced from the ticket system, when they attempt to login but are present with evidence of their account having been locked. [22:33:54] so then they can fill out that form and it goes into the ticket system. [22:37:05] Ugh I was just logged out of English Wikipedia account; did Wikimedia log everyone out of their accounts again? [22:37:13] That's twice in less than a month. [22:38:20] and when did they add a minimum of 10 characters to passwords? [22:38:35] Grrr...my passwords are always strong, but 9 characters. [22:38:46] password length does not equal strength [22:49:14] Something like the way this edit request script works ( https://en.wikipedia.org/wiki/User:Awesome_Aasim/editrequest ) and makes use of [[Special:BlankPage]]. If we could use that special page somehow on the login rejected page in order to integrate an externally-sourced e-mail ticket form, that'd be ideal 🙂 [22:49:14] [WIKIPEDIA] User:Awesome Aasim/editrequest | "Answer Edit Requests (AER) is a (somewhat experimental) tool that allows for processing and answering edit requests. Importing the script does not do anything, but when you visit this page, you will be able to browse and answer edit requests.Note: this is not a replacement for the edit protected helper..." [22:51:15] > password length does not equal strength @Doug No but length is the most important factor in password strength these days [23:00:53] @Void Really? Even when my password uses a variety of CaSiNgS and one or num3r5 and one symbol (&)* * Not necessarily that symbol.