I noticed, that the newtalk flag is not always cleared.
A tiny patch (reordering and calling savesettings) in User.php solves this.
...
function setNewtalk( $val ) {
$this->loadFromDatabase(); $this->mNewtalk = $val; $this->mTouched = wfTimestampNow(); # invalidate cache directly here $this->saveSettings(); # immediately savesettings; finished
}
....
Version: 1.4.x
Severity: normal
jeluf wrote:
There's only one function calling User::setNewtalk(). This is the code:
if ( 0 == strcmp( $this->mTitle, $wgUser->getName() ) ) {
$wgUser->setNewtalk( 0 );
$wgUser->saveSettings();
} else {I don't see that calling saveSettings() within setNewtalk() would help a lot.
JeLuF,
I *reopened the bugzilla* and explain thoroughly:
WITHOUT my patch, the mediawiki versions < REL1_4 have this bug:
Assume you are User X and logged-in as X.
Edit the User_talk page of User Y.
Now logout and re-login as User Y
"You have new messages" is shown
!! DO NOT VISIT User_talk:Y page until I say so
Click on recent changes.
Click onto Main_page (WikiLogo)
Then goto User_talk:Y page / remark: the "you have new messages" marker is
suppressed, when you visit your user_talk page, so you do no know if it is
cleared or not/
This visiting step _should_ clear the marker, but you cannot see it, because the
display is suppressed as explained.
Now click again onto Recent Changes
........ and, surprise, surprise, the wiki shows again the marker "You have new
messages", despite the fact that you just visited the user_talk page.
invaluable.
Try my patch please.
JeLuf,
you are right w.r.t. to the locations of the "savesettings" call.
Please allow me to further investigate, what really happens here (the
non-clearing of the new message flag is a cache problem) and then I will close
this bug.
Okay ?
jeluf wrote:
How is server side DB entry change browser related?
FireFox 1.0, MacOS X
JeLuF:
I reverted my patch and could not reproduce the problem (now) with NETSCAPE 7.1
I fully agree with closing the bugzilla now.
There is a problem somewhere and I am going to find it (later), but it appears
to be browsercache related.
Closing ok.
(When I have new information, I will reopen this bugzilla)