UserQuery does not report correct login times

[benjamin.weaver@…]

I'm trying to use the UserQuery macro to view login times to determine user activity. However, the login times reported are obviously wrong. Some of our most active users have login times 6 months or more in the past.

I'm using Trac 1.0 & AccountManagerPlugin 0.4.4.

[benjamin.weaver@…]

It looks like this might be a duplicate of #6419. In that case, the problem was never addressed because the reporter never followed up. I don't want that to happen here, so here is the full system information that was requested back in #6419:

Trac: 1.0
Babel: 0.9.4
Docutils: 0.6
Genshi: 0.6 (without speedups)
mod_wsgi: 3.2 (WSGIProcessGroup WSGIApplicationGroup %{GLOBAL})
Pygments: 1.1.1
pysqlite: 2.4.1
Python: 2.6.6 (r266:84292, Jan 23 2014, 10:39:35) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)]
pytz: 2010h
setuptools: 0.6
SQLite: 3.6.20
Subversion: 1.6.11 (r934486)
jQuery: 1.7.2

[Steffen Hoffmann]

Hm, account manager plugin just reads from Trac db table, so there must be something going wrong with updating 'last_visit' column values in there.

Unlike with the original macro there is a way to double-check this by going to accounts admin panel provided by this plugin. Can you confirm the wrong last-login record there?

[benjamin.weaver@…]

Yes, I see the exact same dates in the Users admin panel as in the UserQuery macro.

[Ryan J Ollos]

Replying to hasienda:

Hm, account manager plugin just reads from Trac db table, so there must be something going wrong with updating 'last_visit' column values in there.

From memory, I think you are correct about the problem being with Trac. I believe that last_visit will only update when the session data is saved and last_visit is more than 1 day old. See comments in ​bh:comment:10:ticket:554. We might want to try and improve the behavior in Trac.

[Steffen Hoffmann]

Replying to rjollos:

From memory, I think you are correct about the problem being with Trac. I believe that last_visit will only update when the session data is saved and last_visit is more than 1 day old.

I checked this before and this is what I've seen too. However, since I got the impression that session data is saved rather often, I didn't expect some user to log-in and do anything on the site without the session getting updated.

I must be wrong than, but still have no idea how to fix it without adding code, that really should be part of Trac core; right?

[Ryan J Ollos]

Replying to hasienda:

I must be wrong than, but still have no idea how to fix it without adding code, that really should be part of Trac core; right?

We could update last_visit in LoginModule._do_login: ​browser:/tags/trac-1.1.5/trac/web/auth.py@:130#L130. Would that require a change in AccountManagerPlugin also since trac.web.auth.LoginModule is disabled when using AccountManagerPlugin, or is trac.web.auth.LoginModule._do_login still called in your code via inheritance?

[Ryan J Ollos]

Replying to rjollos:

We could update last_visit in LoginModule._do_login: ​browser:/tags/trac-1.1.5/trac/web/auth.py@:130#L130.

See ​trac:#12100.

[benjamin.weaver@…]

It seems to me that it could take an arbitrarily long time to get this incorporated into the main Trac code. Is there any reason why the AccountMangagerPlugin code can't do the updating itself? I kind of need this fix right now, not months down the road.

[Ryan J Ollos]

Replying to benjamin.weaver@…:

Is there any reason why the AccountMangagerPlugin code can't do the updating itself? I kind of need this fix right now, not months down the road.

​PatchWelcome. I'll be pushing out a new release of AccountManagerPlugin, but there hasn't been much development activity lately and I doubt I'll have time to investigate this issue soon.

[benjamin.weaver@…]

I have been traveling most of November. I'll take a look at the code myself, I guess.