Page MenuHomePhabricator

Clear new messages flag for anonymous users after a few months
Open, LowestPublicFeature

Description

Author: lunasantin

Description:
This isn't the most common problem, but I have seen it come up a few times where some poor soul on a dynamic IP gets a vandalism warning that's several months old and panics. Can also be an issue on shared IPs, but on a much shorter time scale. Unfortunately, I have no idea whether it would be difficult or easy to make the Orange Bar of Death eventually "time out" after a few weeks or months (possibly just for IP users), so I'll pop it up here for consideration.

Additional keywords for searching: Expire the newmessages status from unregistered accounts

See also

Details

Reference
bz14396

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 10:14 PM
bzimport set Reference to bz14396.
bzimport added a subscriber: Unknown Object (MLST).

Prio: normal->lowest
Component: general/unknown -> user interface

matthew.britton wrote:

Was just allocated a new IP address and told that I had a "new message" from 2008, reminded me of this issue.

MediaWiki should really be doing this, I think, even if only as an option. It's pretty basic, and for new users it causes confusion and the appearence of hostility. A scan through any regular recent changes patroller's user talk page history, mine included, will reveal several messages from anonymous users questioning why they were warned for a change they did not make -- and inevitably, going to that user's talk page reveals a message months or often years old, intended for a previous user of the IP address. The same situation is repeated across various help pages.

Even on the off-chance that it really is the same person a year and a half later, they're unlikely to care about or even remember whatever prompted the previous message. Especially on large wikis, where most messages sent to anonymous users are templates anyway.

I would recommend three months as the default timeout for the "new messages" flag.

matthew.britton wrote:

Looking at the DB structure, the user_newtalk table has a user_last_timestamp field that I assume is intended to hold the timestamp of the most recent revision to the user's talk page, but which does not appear to be used. Think implementing this is dependent on that being populated.

Jason_quinn wrote:

Another idea is to change the text of the message for IP edits such that the user is aware that the message may not apply to them.

(In reply to comment #3)

Looking at the DB structure, the user_newtalk table has a user_last_timestamp
field that I assume is intended to hold the timestamp of the most recent
revision to the user's talk page, but which does not appear to be used. Think
implementing this is dependent on that being populated.

I don't think WMF projects have the column yet.

matthew.britton wrote:

(In reply to comment #5)

(In reply to comment #3)

Looking at the DB structure, the user_newtalk table has a user_last_timestamp
field that I assume is intended to hold the timestamp of the most recent
revision to the user's talk page, but which does not appear to be used. Think
implementing this is dependent on that being populated.

I don't think WMF projects have the column yet.

That doesn't prevent the feature being implemented in trunk.

Last time I checked, however, I couldn't find the field in use *anywhere* in the code, and I assumed someone had proposed a schema change that got through but then forgotten about the feature. Has this situation changed?

Because of votes rasing importance/priority according to following scheme:
15+ votes - highest
5-15 votes - high
Community must have a voice within development.

Regards, Kozuch
http://en.wikipedia.org/wiki/User:Kozuch

Is this still an issue? Are there complaints about this problem nowadays?

A year of silence. I wonder whether this is still a problem nowadays, or whether messages for IP addressess do get deleted after certain period.

Changing priority to Lowest in order to reflect the fact that nobody is working or planning to work on this.

Is it possible in the near future that somebody will solve this ask? On huWiki we are still waiting and hoping.

@Bencemac: Nobody is working on this (reflected by the Assignee) and nobody plans to work on this (reflected by the Priority), hence patches are welcome!

Tacsipacsi changed the subtype of this task from "Task" to "Feature Request".Jan 10 2022, 9:25 PM
Tacsipacsi added a project: Hungarian-Sites.
Tacsipacsi updated the task description. (Show Details)
Tacsipacsi subscribed.