jhl, make sure their browser is accepting cookies correctly. Can you just ask them to try with another browser/pc?
Already done, they have tried IE and Chromium (though I cannot confirm, because I can't see their computer). I have one user who seems to have fixed the problem using the 'Remove cookie' link, but three who are *still* stuck.
The diagnostics seem to be that:
1. New (x) worked previously, IP 1.3.0.53b till the switch over, in mid August (16th IIRC)
2. After upgrading to IP 2.0.0.86 four users have reported this problem - but there may be more who have not shouted out. All Windows, 1 Firefox, 1 Chromium, 1 IE8. Two have switched browser, to no avail. All have tried using the 'Remove cookie' (Elimina cookie in italiano) link, only one worked, and he already had a 'Last visit' date of yesterday, not the middle of August. The other three have 'Last visit' dates prior to the switch over (prior by about 1-3 days).
It's like the logout function doesn't get called for them - perhaps their cookie gives a 'unregistered user' value? I'm looking at the code, but struggling to understand what comes from where, DB or cookie.
Regarding the request to "impersonate" a user, with the new user class it should be possible by instantiating a new $user class and temporarily store personal user data to another array... It has not been implemented yet, if you wish you can try to do it.
I might at that. It may help in some debugging situations, but will need a new field in the DB. Admins only, of course. It depends if a different 'quick fix' fails...
The real issue with that approach is that you should also create a new "dummy" cookie with all user data, which it is simply not possible because cookies are stored on another pc and there are no data regarding cookies in the DB, so you cannot know what the real situation is for that user.
OMG Luca, how much stuff is stored in the cookie???!!! Here on IP, my cookie says:
which doesn't seem too much. Topics read/unread in icyphoenix_t, I imagine. _u is user, _sid is sid, but _k? I don't think the __umtx values have anything to do with IP, though goodness knows where else they come from...
I'll see if I can get those users to screenshot their cookie values. Then I will ask the users to delete the cookie via the browser. This is a quick fix of course, but the original problem still remains - if it can be confirmed by other users of IP 2.x, of course.
If that doesn't work, I'll try duplicating the cookie value of a user, then impersonating him/her. Really the only values not from the DB anyway are _t and _k, right?
mort, spydie, as specified in another topic, NEW is different from UNREAD (a new message is a message posted after your last visit regardless it has been read or not, an unread message is something you didn't read, or marked back as unread). If you want to keep track of all unread posts, the only solution is UPI2DB.
mort,
spydie See
http://www.icyphoenix.com/viewtopic.php?f=2&t=8651 and
http://www.icyphoenix.com/viewtopic.php?f=10&t=8136
John