Fri, May 14
Does only the technical implementation (rights assignment) move to the stewards, or also the decision the rights are to be assigned?
Do local policies remain in place, or are they overridden by a new global policy?
Wed, May 12
The current requirement is that one has to have 2fa enabled at the time when IA rights are applied, but there is neither a policy (is it?) nor a technical reason not to disable 2fa at any time later. Will stewards review or monitor this in any way?
A more simple approach from the bureaucratic point of view would be to technically check the 2fa status by the software at the time the group rights are to be used, so that IA (or say CU) features can only be used when 2fa is enabled at that time. This of course would require a software change, but it appears to be a much more reasonable and flexible way to me.
Apr 9 2021
I would like to withdrawn the request. Can be done later.
Apr 3 2021
Jan 22 2021
Database s51441_krdbot can be immediately deleted.
Jan 8 2021
Oct 6 2020
Disclosure: I did not participate in the vote, but it is know that I'm supportive of the idea for years.
Sep 24 2020
Sep 18 2020
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.
Sep 17 2020
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.
Aug 2 2020
Jun 24 2020
Looks good to me. Please also include checkuser.wikimedia.org and steward.wikimedia.org.
May 20 2020
As said, I can do that, but I don't think too much detail is required anyway.
We can use bots currently on private wikis with username and good passwords. If we had bot passwords, we could enable 2fa on the bot account and limit the bot password to the fixed IP of the private server the bot runs at. This will in any case highly improve security, with likely not any loss.
If you ask me, this is a nobrainer.
Please feel free to do so.
Please advise what is needed to push this forward.
Mar 2 2020
Perhaps I could, but definitely not in a public ticket.
No, I don't want to wait for such feature.
I'd say as long as there is no 2fa requirement on these private wikis, anybody can technically share his password, so using bot passwords does not reduce security per se. But it can increase security, so I like to have it.
Perhaps access to bot passwords could require a user right?
That is of course a valid concern.
I cannot speak for others, but my intention is to lock the bot account by 2fa and use the bot password with strict IP limit, to get additional IP filter security.
Feb 29 2020
I could imagine it was not enabled at private wikis because there are usually no bots running there. As things are growing and automation is generally a good idea, it should be enabled on all private wikis if there are no real reasons against.
Feb 28 2020
Feb 13 2020
Invalid request, please contact OTRS admins via e-mail to firstname.lastname@example.org.
Dec 25 2019
A formal deployment freeze sounds reasonable. Can you please advise for which day the change can be scheduled, so we can decide if an expensive interim solution is required, i.e. temporarily moving the whole stuff to a different e-mail address?
Re-adding an MX record is not rocket science, this should be possible also at this time of the year, and not noticing missing e-mails if a different thing than actively ignoring a broken setup. IMHO.
Could anybody please explain why such an easy task does takes so long to get resolved? What can be done to expedite?
Dec 21 2019
One could consider https://otrs-wiki.wikimedia.org/wiki/Administrator_requests as a better venue for such requests.
Sep 6 2019
Jun 12 2019
The notifications appear to be sent:
From email@example.com Sun Jun 02 08:02:02 2019
From: OTRS Notifications <firstname.lastname@example.org>
Dec 1 2018
What is a reasonable time? For OTRS wiki time of is around "some hours" sometimes, which is quite annoying. I also noticed delays at arbcom-de.wikipedia.org, but at a lower level, around several minutes.
I notice that pages require purging after template changes. Not a big deal if it cannot be resolved, feel free to close the task. Thx.
Nov 15 2018
Aug 13 2018
Jun 21 2018
Mar 26 2018
Negative. If an e-mail address has been redirected, OTRS admins shall to be informed accordingly to remove the e-mail address from OTRS and close the related queues, in order to avoid tickets being moved to a queue that is no longer read, or e-mails getting CCed to an address that is still considered internal and never sent out.
Straight away I don't know if and how this could be done, this would require some research, ad I think we need root support for this. @akosiaris could be the person to ask.
Mar 12 2018
Apr 20 2017
Jan 7 2017
The system is up again, and the dashboard look good to me.
Dec 20 2016
Dec 16 2016
Dereckson: There is no "meanwhile", the button worked directly since it was introduced, and this is a breaking change now.
(Side effects of accidental use, if there are any at all, are irrelevant as no actual data is deleted.)
The button worked directly, without confirmation. The confirmation popup breaks workflow, breaks display on small screens, costs time, is annoying, is not needed.
Time and dedication to the projects are the values we have in volunteers. A tool that costs time and is annoying, for no benefit at all, is the worst case scenario, and I wonder how one could not see that before deployment, and I'm speechless that this has to be explained.
Please revert this change globally. Totally unusable, complaints on all major wikis.
Nov 11 2016
Filters have been created to move these tickets to Junk, so for the moment I consider this resolved.
Oct 20 2016
@DatGuy: Please discuss the content of the message on OTRS wiki.
Oct 19 2016
Oct 11 2016
Looks good for me, but I'm not sure yet of the old values are ok for all users.
There appear to be some database issues with ticket notification settings that need further investigation.
Can you please check that?
Jun 14 2016
Apr 24 2016
Strong oppose. No need, more problems created than resolved, if any resolved at at.
Additionally, no prior discussion has taken place at the appropriate venue, which would have been the OTRS admin mailing list.
Feb 17 2016
I cannot make any well-informed call if this will be uncontroversial, but I think crats are not in charge here anyway. IF if could be controversial, it should be discussed within the community.
Nov 10 2015
Some of the admin interface views did, sadly not reproduceable at the moment.
Understood so far, but having that we cannot test functions that use expensive database queries when they run into timeouts, besides that it's not a lot of fun to do tests at all on slow systems.
Sep 28 2015
Just if anyone cares, after nearly 2 years I have somewhat lost interest in this issue, so I'm fine if somebody closes this at not done.
Jun 14 2015
Apr 17 2015
If I'm not mistaken, the problem appeared at beginning of this week.