@eoghan Does ticket archiving make the tickets inaccessible from the web interface? If so, we can't do that as that will break permissions links.

Right now, we assume that all of the Toolforge Databases are created. That includes meta_p. We are working on removing that assumption as part of T344090: Revive third party support

This also applies to the "hist" link to the right

Let me know if I can help with this at all.

@JJMC89 Thank you! I wonder if there's a way to have XTools ignore tables that aren't completed.

This now shows up on enwiki, probably due to software deployment this morning.

Further details located at https://phabricator.miraheze.org/T2061

Okay, the snarky comments were unnecessary.

In T283980#7136131, @DannyS712 wrote:

In T283980#7136114, @stjn wrote:

In T283980#7135209, @mmodell wrote:

Several of Phabricator's users and long time contributors are coming together to fork phabricator, with @epriestley's blessing and under a new name. I hope that Wikimedia will be a part of that effort, at least by sponsoring some of my time towards it, however, I intend to contribute in a personal capacity as much as I can.

Please name it Phork. Please name it Phork.

+1 to the name suggestion, but is there also any public documentation about this discussion and fork? I'd be interested in following along (and I'm sure others on this task would be too)

In T280392#7031243, @Bluerasberry wrote:

community has feelings about the name of this and I think the name choice should be a community discussion

see past conversation with lots of participation

https://meta.wikimedia.org/wiki/Talk:OTRS/Archives/2019#Proposal_for_name_change_-_%22Wiki_client_services%22

propose that there be a conversation before anyone takes action at scale

Also, the idea of centralizing the OTRS authentication has been discussed and rejected before: T133476: Proposal: Centralize OTRS login methodology. I proposed setting up an LDAP server years ago that would handle the authentication and role management, and the overhead was too high.

https://otrs-wiki.wikimedia.org/wiki/Greasemonkey_Scripts (Feel free to expand or rename) - I also ported to GitHub as opposed to the Paste, which was more maintainable.

In T263243#6475206, @Krd wrote:

Can you please put or link this somewhere on OTRS wiki? I think there are some more Greasemonkey scripts, at lease I have one that is a bit useful.

Hey, I don't know if this helps a lot, but I built a quick GreaseMonkey script that should restore the colors: https://github.com/Matthewrbowker/otrs-colors/raw/master/otrs-colors.user.js . This should work short-term until we decide what to do with our OTRS install.

In T122220#6473842, @akosiaris wrote:

In T122220#6471605, @Matthewrbowker wrote:

In T122220#6471256, @Krd wrote:

I appreciate that we have that feature now and do test it, but I second akosiaris' statement above that we don't have any process yet to recover an account. I guess if anybody locks out themselves at the moment we could be unable to recover the account. Please consider that OTRS admins may not have enough resources for assistance at the moment.
If 2fa forces us to rely on anything not verifyable during account recovery, it perhaps doesn't add much additional security.

This is my biggest concern as well. My feeling, at least for the trial period, would be to require a post to [[AR]] on OTRS wiki. But, if we have to remove their 2FA token we also scramble their password and force them to reset it.

Long-term, we need a better solution (like a committed identity that enwiki has) - but all of that is taking more time from an already stretched thin admin team.

Another question/idea would be: How hard are OTRS modules to build? We could theoretically build an enhanced version of the built-in 2FA module, which allowed for scratch codes and hide the generator token.

A more suitable question would be "How costly are OTRS modules to maintain?" as I my experience up to now with OTRS modules is that most of their cost goes into maintenance and not building them. And since we would be probably patching the current implementation, it would be considerable. We would need to find someone to do build it and maintain it down the road.

In T122220#6471256, @Krd wrote:

I appreciate that we have that feature now and do test it, but I second akosiaris' statement above that we don't have any process yet to recover an account. I guess if anybody locks out themselves at the moment we could be unable to recover the account. Please consider that OTRS admins may not have enough resources for assistance at the moment.
If 2fa forces us to rely on anything not verifyable during account recovery, it perhaps doesn't add much additional security.

@DannyS712 Awesome, thank you for taking care of that!

I have also enabled 2FA on my account. It's a bit of a scary process currently - I'm used to being asked that 2FA is set up correctly by inputting a code. Instead, the interface just assumes that you're set up correctly, which makes it easy to lock your account.

+1 to the lab rat queue, I'd love to test this.

In T262399#6450086, @Cyberpower678 wrote:

Isn’t the edit counter supposed to issue a replay warning in these instances?

That's why I didn't tag any project admins yet, I wanted to open it for wider discussion from the XTools maintainers before I went ahead and implemented.

@MusikAnimal @Cyberpower678 Do we want to use the banner system to maybe add a message linking to T262239 on prod? Otherwise, I fear we're going to see multiple tasks related to this.

In T247900#5977553, @Zppix wrote:

In T247900#5977547, @Matthewrbowker wrote:

In T247900#5977515, @Zppix wrote:

In T247900#5977505, @Matthewrbowker wrote:

For the record, I'm against this change. If there's truly an issue, a trusted contributor with a WMF cloak can bangops just as easily. But by whitelisting other networks, it becomes trivial to social engineer enough to begin creating spam. And I know a couple of our bad actors would love that.

Why can't a trusted contributor without a wiki cloak be given the same rights as one with one?

Wiki contributors are vetted using OAth, requiring 250 edits, three months service, and no active blocks. I consider that pretty low bar, certainly not something would preclude someone who is hanging in our channels actively to achieve.

And if not, someone with a cloak can bangops. Or go to #wikimedia-ops and ask for help.

What about for example for users like myself, who meet those criteria for a cloak, but have a cloak with a different project?

In T247900#5977515, @Zppix wrote:

In T247900#5977505, @Matthewrbowker wrote:

For the record, I'm against this change. If there's truly an issue, a trusted contributor with a WMF cloak can bangops just as easily. But by whitelisting other networks, it becomes trivial to social engineer enough to begin creating spam. And I know a couple of our bad actors would love that.

Why can't a trusted contributor without a wiki cloak be given the same rights as one with one?

For the record, I'm against this change. If there's truly an issue, a trusted contributor with a WMF cloak can bangops just as easily. But by whitelisting other networks, it becomes trivial to social engineer enough to begin creating spam. And I know a couple of our bad actors would love that.

After some testing, this appears to affect all tools. Therefore, I'm putting the code into the User module rather than the GlobalContribs controller.

In T218485#5031203, @MusikAnimal wrote:

We could remove the hyphen and keep the parentheses, as you suggest, but I see nothing linguistically incorrect with the status-quo. I believe this presentation was the same in the older version XTools, so it's been around for years.

Hello, @Adithyak1997, thank you for the bug report. What exactly is the problem? Are you concerned about the fact that we put the word "Semi" in parenthesis? Are you talking about the word "HIde" which is in brackets? Or did I completely missunderstand?

A quick eyeball at the emails show it's a pretty standard "spoofing our email as a from address and reply-to address" spam. This happens about once every six months to a year but this is by far the biggest I've seen.

Since I did most of AdminStats, I’ll take this on.

And I've switched the instance to wm-bot, since that seems to be the standard in all of the tech channels.

I've set #wikimedia-tech and #wikimedia-dev to +rf #wikimedia-overflow. It's not an ideal solution but it is a solution, hopefully we'll be able to increase productivity in those channels. #wikimedia-overflow has a large op presence that can either invite users or solve the issues.

If you set a +r and +f, I would recommend #wikimedia-overflow, as it already has a topic with those instructions and a large chanop presence who can handle the messages as needed.

Actually, after further digging it appears to be related to Intuition. @Krinkle where would be the best place for us to request additions to language/mw-classes/Names.php?

It appears to be related to TranslateWiki, see message stats