Wed, May 20
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 email@example.com.
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 firstname.lastname@example.org Sun Jun 02 08:02:02 2019
From: OTRS Notifications <email@example.com>
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.