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?

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.

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().

In T185664#3926198, @stjn wrote:

In T185664#3926196, @TheDJ wrote:

@stjn almost everything we do creates 'massive outrage'. It's important however that options are simply explored, even if they may seem undesirable or possibly even unrealistic.

And by commenting I am trying to say that this is not an option worth exploring. Undeploying without anything else instead is as viable of an option like undeploying AbuseFilter is (albeit it, too, has problems with extension support).

Are there any plans to move forward with this?

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.

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.

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.

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.

In T165535#4038869, @TBolliger wrote:

• If the block reason is a template, it should display as a link. On tap it should display the parsed template.

I think this might be problematic because transcluding changes the apperance of many templates especially if additional parameters have been specified.

@Huji: Thank you very much!

In T188960#4033706, @Niharika wrote:

In T188960#4033464, @MGChecker wrote:

Just a( (late) idea: Maybe we could just suppress summary notifications on minor edits? This would be similar to how nominornewtalk works.

Is it the case that people would not like to ping other people for minor edits they've made? This seems like two mutually exclusive things and I'd not favor adding a dependency unless we're absolutely sure.

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.

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.

Just use MediaWiki system messages for these things, as we always do it this way.

In T6715#4017386, @Anomie wrote:

While there's still some backend cleanup work needed (see T166733), comments longer than 255 bytes are now allowed.

In my opinion, this needs to be reverted as soon as possible, as there is no frontend adjustement for this change whatsoever.

Nevertheless, this task can't be done until T184791 is done.

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?

This can't be done easily as custom signatures contain text in nearly all cases. This text would need to be localized.

Don't forget assigning the permission to view the new log to ombdusmen and stewards as well :)

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)

In T184309#3970587, @Niharika wrote:

In T184309#3970573, @Samwilson wrote:

• are we talking about log entries for log entries being deleted or are we talking about log entries which deal with deletion of stuff on the wikis? If we're talking about the former, I'd err on the side of caution and skip thanking anything. If we're talking about the latter - I'm not sure why we would be thanking the deleted user -- shouldn't we be thanking the person who deleted the user or the person who deleted the offensive action?

So my understanding is that a deleted log entry (i.e. one which all fields should be taken to be deleted) is a "restricted" deletion. These can still be seen by users with the suppressrevision right, and those users might want to be able to thank for them.

Log entries with other deletion types (comment, action, and user) can be seen by users with the deletedhistory right. They also might want to thank for these?

A "comment" deleted log entry is one that's just got its comment deleted. (Umm... I think? I mean, that's supported, but does it ever happen?)

I can imagine someone creating a log entry with an offensive comment and that being deleted. But that's probably very rare.

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.)

I think we shouldn't do any private logs like checkuser-log or suppressionlog.

Why won't pipes be supported? They can help to make the namespace invisible so the summary is more readable.

This isn't the same diff, @Amire80. The thanks link is displayed neither in the history nor in the diff.

In T32750#3942639, @Niharika wrote:

It's possible to add a second textbox where users could add users to be notified. It wouldn't be recorded in the edit summary. Something like...

But of course, it's more work to build and we won't be able to do it within Echo, as far as I can tell.

In T60485#3939377, @Samwilson wrote:

It sounds like a log type (and not subtype) blacklist is still the easiest thing then.

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.

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.