(Assuming tag was kept because it's in the parent task, not that this particular task has been suggested for the newsletter.)

• There are currently two types of thank: flow and rev. We'll add log to this.
• The unthankable log types will be defined by a config variable, defaulting to thanks and newusers types (with subtypes ignored).
• A 'thanks' link will be added to the end of every log line (with LogEventsListLineEnding hook; and only for thankable entries)
• Currently, thanks (when not sent direct to the API from JS) are processed by a link like Special:Thanks/<type>/<id> (e.g. Special:Thanks/Flow/u6rogxorjxvg2xs6) where <type> is optional and if it's an integer is assume to be a revision ID. This will still be fine for the addition Log type.
• There are two API modules, thank (with rev and source parameters) and flowthank (with a postid parameter). We'll add logthank to these, with a logid parameter. Alternatively, we could merge all these into one thanks module, with type, id, and source parameters (etc.), which would be a bit neater.
• The Echo notification won't be a link, because it can contain all of the log info (basically just the line as it appears in Special:Log, but formatted for better display). There's also no way to link to a single log entry (could link to log type, performer, year, and month though).
• The discussions have mentioned changing the edit-thanking message to something like "thanks for this action" but there's no need for that; we can have separate messages.
• We'll rename the ext.thanks.revthank module and generalize it to handle both rev and log thanks.

In T184309#3933549, @Samwilson wrote:

• The Echo notification won't be a link, because it can contain all of the log info (basically just the line as it appears in Special:Log, but formatted for better display). There's also no way to link to a single log entry (could link to log type, performer, year, and month though).

Are there any current notification types that are not links?

• The discussions have mentioned changing the edit-thanking message to something like "thanks for this action" but there's no need for that; we can have separate messages.

Good to know! I think this would be a better experience. Will we be able to construct a message such as "Bob thanked you for your block of User:123" or "Bob thanked you for your deletion of Foobar" ? Or do all log thanks need to have the same generic text? (If so, we will need to think how to link to the log entry so a user will be able to determine exactly what they were thanked for.)

In T184309#3935012, @TBolliger wrote:

In T184309#3933549, @Samwilson wrote:

• The Echo notification won't be a link, because it can contain all of the log info (basically just the line as it appears in Special:Log, but formatted for better display). There's also no way to link to a single log entry (could link to log type, performer, year, and month though).

Are there any current notification types that are not links?

Commonly "Welcome to X wiki!" and "Congratulations on your 100th edit!" type of notifications are not links. "User:A sent you an email" type of notifications are also not links.

Thanks Niharika!

My first question for @Samwilson still (patiently!) awaits an answer:

Will we be able to construct a message such as "Bob thanked you for your block of User:123" or "Bob thanked you for your deletion of Foobar" ? Or do all log thanks need to have the same generic text? (If so, we will need to think how to link to the log entry so a user will be able to determine exactly what they were thanked for.)

@TBolliger sorry! :-) And no, we probably can't have the message be log-type-specific, but we can have different ones for revisions and log entries:

	"notification-header-rev-thank": "$1 {{GENDER:$2|thanked}} {{GENDER:$4|you}} for your edit on <strong>$3</strong>.",
	"notification-header-log-thank": "$1 {{GENDER:$2|thanked}} {{GENDER:$4|you}} for your action relating to <strong>$3</strong>.",

	"notification-bundle-header-rev-thank": "{{PLURAL:$1|One person|$1 people|100=99+ people}} thanked {{GENDER:$3|you}} for your edit on <strong>$2</strong>.",
	"notification-bundle-header-log-thank": "{{PLURAL:$1|One person|$1 people|100=99+ people}} thanked {{GENDER:$3|you}} for your action relating to <strong>$2</strong>.",

But maybe putting the log type name in there would work, e.g. $1 {{GENDER:$2|thanked}} {{GENDER:$4|you}} for your $3 action relating to <strong>$4</strong>." where $3 is 'delete' etc.?

Perhaps we could create messages for the more common log types, and fall back to a generic one? e.g. notification-header-thank-log-delete is $1 {{GENDER:$2|thanked}} {{GENDER:$4|you}} for your deletion of <strong>$4</strong>."

@TBolliger, @Samwilson : I imagine we'll need to put a big switch statement in the notification formatter class and have a customized message for most of the log types if we aren't linking to anything. Otherwise, people are likely to get confused. We could have a generic fall-back though, as Sam suggests. This means we'll probably want to make the log types that are supported opt-in rather than opt-out (as proposed by Sam above). Making them opt-out seems dangerous anyway. I doubt people who create new log types (like the upcoming page creation log) are going to remember to remove their logs from the Thanks feature if it doesn't make sense for them.

In T184309#3950946, @kaldari wrote:

@TBolliger, @Samwilson : I imagine we'll need to put a big switch statement in the notification formatter class and have a customized message for most of the log types if we aren't linking to anything. Otherwise, people are likely to get confused. We could have a generic fall-back though, as Sam suggests. This means we'll probably want to make the log types that are supported opt-in rather than opt-out (as proposed by Sam above). Making them opt-out seems dangerous anyway. I doubt people who create new log types (like the upcoming page creation log) are going to remember to remove their logs from the Thanks feature if it doesn't make sense for them.

I 100% agree. Well said, Ryan.

With regard to the messages, there's the header but also the 'excerpt' message of the notification itself. This can be the log entry's "action text", which is what's shown on Special:Log. For example, for a deletion it could look like:

This has the advantage of not having to define any new messages, but perhaps isn't as neat as it could be.

In T184309#3951676, @Samwilson wrote:

With regard to the messages, there's the header but also the 'excerpt' message of the notification itself. This can be the log entry's "action text", which is what's shown on Special:Log. For example, for a deletion it could look like:

(User:Admin did the deletion, User:User thanked em.)

This has the advantage of not having to define any new messages, but perhaps isn't as neat as it could be.

I like this actually. We could modify it a bit like -

That's a good idea @Niharika. One thing though, we can't have a link to the action, because there's no Special:Log?log_id=123 or similar place to link to. The current thing is to link to the log entry target page (i.e. in the case of a deletion, this rather confusingly links to the deleted page). Echo also wants a Title to link to, not just any URL.

@Samwilson Yeah, I missed that. No link is fine. We can also move the latter (action) part User:Abc deleted page XYZ to the secondary message if that'd look better? I think we can experiment with this a bit and see what works best.

Through a space after the colon and it looks good to me!

I assume Echo automatically handles long usernames and long pagenames?

In T184309#3933549, @Samwilson wrote:

There's also no way to link to a single log entry (could link to log type, performer, year, and month though).

The best we have is Special:Redirect/logid/87654321, but it's a bit of a hack and needs to be improved.

In T184309#3956590, @TBolliger wrote:

I assume Echo automatically handles long usernames and long pagenames?

That's the thing I was concerned about. It looks like Echo lets the header message flow into the second line and if it's still long, it truncates it with an ellipsis. I couldn't quite determine the exact limit on it but I *think* it's 100 characters. I'm not quite sure if that will work for us but let's try it!

In T184309#3959985, @TTO wrote:

In T184309#3933549, @Samwilson wrote:

There's also no way to link to a single log entry (could link to log type, performer, year, and month though).

The best we have is Special:Redirect/logid/87654321, but it's a bit of a hack and needs to be improved.

Ugh. That's not a very pleasant hack. Does it work for every log type though?

Seems to work even with custom log types: https://en.wikipedia.org/wiki/special:redirect/logid/88504040

It doesn't handle collisions (i.e. where the same user carries out the same logged action more than once in the same second), but since virtually all instances of that will be carried out by bots, who cannot be thanked, I don't think it's a big issue.

That's a good trick for the log_id link.

With regard to deleted log entries, what's the desired behaviour? Log entries have four types of deletion: action, comment, user, and restricted. The simplest case is to not permit thanks on any sort of deleted log entry. And certainly it doesn't make sense to thank a deleted user, nor probably a deleted action. But permitting thanks even where there's a deleted comment, or fully restricted log entry, might make sense? I'm afraid I don't really know enough about how sysops and oversighters work.

In T184309#3966053, @Samwilson wrote:

That's a good trick for the log_id link.

With regard to deleted log entries, what's the desired behaviour? Log entries have four types of deletion: action, comment, user, and restricted. The simplest case is to not permit thanks on any sort of deleted log entry. And certainly it doesn't make sense to thank a deleted user, nor probably a deleted action. But permitting thanks even where there's a deleted comment, or fully restricted log entry, might make sense? I'm afraid I don't really know enough about how sysops and oversighters work.

I'm not 100% clear on what you're talking about -- 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?

In general though, we should skip allowing thanks for anything we're unsure about.

In T184309#3969797, @Niharika wrote:

I'm not 100% clear on what you're talking about

That makes two of us! :-)

• 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?)

A "user" deleted log entry is one that was performed by a user who's been deleted, so there's no thanks needed there.

An "action" deleted log entry has had its action deleted. Could conceivably still want to thank for that?

So yeah, all up, it's confusing but I think we can skip thanks for any sort of deletion!

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.

A "user" deleted log entry is one that was performed by a user who's been deleted, so there's no thanks needed there.

An "action" deleted log entry has had its action deleted. Could conceivably still want to thank for that?

So yeah, all up, it's confusing but I think we can skip thanks for any sort of deletion!

I'm having déjà-vu. It's like cookie blocks all over.

It seems to me that we might be able to allow thanking for restricted, comment and action deletion types in future. However for now, let's skip thanks for any sort of deletion. I'm gonna put this in a task though, so we don't forget about it.

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.

In my experience, it isn't that rare. I've experienced it multiple times.

In T184309#3972133, @MGChecker wrote:

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.

In my experience, it isn't that rare. I've experienced it multiple times.

That's good to know. @MGChecker what do you think about holding off on thanking for log entry related deletions?

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)

@Samwilson — Since this is now in development (T186855) can we close this investigation ticket and keep all future questions/discussions on T60485?

SG9tZVBoYWJyaWNhdG9yCk5vIG1lc3NhZ2VzLiBObyBub3RpZmljYXRpb25zLgoKICAgIFNlYXJjaAoKQ3JlYXRlIFRhc2sKTWFuaXBoZXN0ClQxOTcyODEKRml4IGZhaWxpbmcgd2VicmVxdWVzdCBob3VycyAodXBsb2FkIGFuZCB0ZXh0IDIwMTgtMDYtMTQtMTEpCk9wZW4sIE5lZWRzIFRyaWFnZVB1YmxpYwoKICAgIEVkaXQgVGFzawogICAgRWRpdCBSZWxhdGVkIFRhc2tzLi4uCiAgICBFZGl0IFJlbGF0ZWQgT2JqZWN0cy4uLgogICAgUHJvdGVjdCBhcyBzZWN1cml0eSBpc3N1ZQoKICAgIE11dGUgTm90aWZpY2F0aW9ucwogICAgQXdhcmQgVG9rZW4KICAgIEZsYWcgRm9yIExhdGVyCgpFVzZSC3IERpc2NsYWltZXIgtyBDQy1CWS1TQSC3IEdQTApZb3VyIGJyb3dzZXIgdGltZXpvbmUgc2V0dGluZyBkaWZmZXJzIGZyb20gdGhlIHRpbWV6b25lIHNldHRpbmcgaW4geW91ciBwcm9maWxlLCBjbGljayB0byByZWNvbmNpbGUu