Last modified: 2014-11-18 18:07:35 UTC
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.
Prio: normal->lowest Component: general/unknown -> user interface
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.
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.
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.
(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.
