Sat, Apr 21
Thu, Apr 19
Is there a date set when to do this? I assumed HHVM compatibility would cover our needs.
What exactly is blocking master to require PHP 7, if even 1.31 is already requiring it?
Sun, Apr 15
Wed, Apr 11
I just retested it, the behavior hasn't been fixed at all. This isn't happening on normal view, so it's definitely an Android app issue.
Mon, Apr 9
Sun, Apr 8
The method in question was removed in https://gerrit.wikimedia.org/r/#/c/386639/ after it has been deprecated since 1.24. Just replace it with WikiPage::onArticleCreate().
Sat, Apr 7
Are there any plans to move forward with this?
Fri, Apr 6
Note that this task wasn't fixed as proposed in the task description, but by adding a option in the parser to mark tags that are problematic in this way.
Thu, Apr 5
Why shouldn't you block IP ranges like that? It's happening all the time that given IPs troll at one specific page…
To maintain backwards compatibility, it should be possible to turn off the new behavior, although it should be expected.
Fri, Mar 30
As user agent based blocking is only allowed in combination with ip r(ange) blocking, the collateral damage shouldn't be really large.
I propose the pages associated with Q4580256 for a mass message or something like that.
Mar 14 2018
If you just change one of these many parameters, the block isn't triggered anymore as the resulting hash is different. The more different parameters we're hashing, the easiert it gets to find some to easily change to do this.
Ideally we will use enough parameters to create very unique fingerprints making it harder to "brute force" the hash
including all patrol actions prior to April 2016
I don't think this is the right approach for removal of autopatrols out of the logging table. Autopatrols before April 2016 are distinguishable, even if not by log_action, and by doing this we would lose a lot of actual data in contrast to removing only autopattrol actions.
Mar 11 2018
I think this might be problematic because transcluding changes the apperance of many templates especially if additional parameters have been specified.
Mar 9 2018
@Huji: Thank you very much!
Mar 7 2018
I agree with @stjn. This change has nothing to do with the community wishlist proposal (which isn't consensus anyway). Non-latin languages have their problems solved already if we move to 255 characters instead of bytes.
Just a( (late) idea: Maybe we could just suppress summary notifications on minor edits? This would be similar to how nominornewtalk works.
This reduction would be a helpful partial fix in any case.
Mar 4 2018
Mar 3 2018
Of course my concern isn't the backend possibility to store longer comments, but that it's possible right now to actually enter any text up to 1000 bytes at the ui.
On the one hand, this isn't an enwiki issue, on the other hand, in my opinion there isn't any need to community discussion reverting problematic changes, this can be done afterwards. If there's a problem, just rest it to the status quo and deal with it afterwards.
Mar 2 2018
Just use MediaWiki system messages for these things, as we always do it this way.
In my opinion, this needs to be reverted as soon as possible, as there is no frontend adjustement for this change whatsoever.
Feb 28 2018
Nevertheless, this task can't be done until T184791 is done.
Feb 26 2018
While I'm certain we won't start evaluating templates in edit summaries just to do this, pipes should definitely be supported. I stated this before at T186655#3954502, getting universal acclaim (including you, @TBolliger ?). However, I'm unsure if this is already incorporated in the merged patch. @Catrope @MaxSem: Is it?
Feb 25 2018
This can't be done easily as custom signatures contain text in nearly all cases. This text would need to be localized.
Feb 23 2018
Feb 20 2018
Feb 17 2018
Don't forget assigning the permission to view the new log to ombdusmen and stewards as well :)
Feb 14 2018
I would allow thanks to all deleted log entries as long as user name and action are visible. However, why should log entry related deletions be special? (Assuming you mean the log entries of deletelogentry-actions in the deletionlog)
Feb 13 2018
Feb 10 2018
I really appreciate your work here! You make sure at least some of these tasks recieve the love they deserve :)
@Huji Any news here?
Making ORES scores available to AbuseFilter as variables would be a relatively easy way to partially fix this.
First of all, it makes this whole thing more complicated. You have to check the accessibility of the log for a given user before delivering a thanks he commited. (Well, you don't have to, as you're technically aren't disclosing any private information, but this leads me to the second point.)
Feb 8 2018
I think we shouldn't do any private logs like checkuser-log or suppressionlog.
Feb 7 2018
Why won't pipes be supported? They can help to make the namespace invisible so the summary is more readable.
Feb 5 2018
This isn't the same diff, @Amire80. The thanks link is displayed neither in the history nor in the diff.
Feb 4 2018
Feb 3 2018
Feb 1 2018
Nevertheless, I want to point out that exactly this idea is the premise of T182480, which lead to the creation of this project. The activity of this subproject makes monitoring the activity of Anti-Harassment really spammy and messy.
I propose to remove Anti-Harassment from the InteractionTimeline related tasks, is there isn't a concrete sprint assigned, as this was the idea of this project to begin with. You don't use Anti-Harassment at all AbuseFilter tasks either.
Yeah, but this actually makes them even more complicated in my opinion, as it would be really contraintuitive to disallow thanks on these log entries if they are possible on all the other ones. The software would have to link the revisions associated with moves, protections and uploads with the log entries to prevent double thanks for some actions. Otherwise, this would be confusing for people who give thanks and such who are receiving them as well.
Jan 31 2018
I just realized patrol/autopatrol will be problematic as well. It shouldn't be possible to thank for these log_action, analogous to thanks/thanks, newusers/create and newusers/autocreate. Tagging via applychangetags might be problematic as well, but you can't distinguish them by log_action. [https://quarry.wmflabs.org/query/24499 1] However, maybe a distinction between change tags added on edit and change tags added afterwards by log_action can be added in the future.