#554: "Last Login" does not update
-----------------------+----------------------------
Reporter: rjollos | Owner: rjollos
Type: defect | Status: accepted
Priority: critical | Milestone: Release 6
Component: plugins | Version: 0.5.3
Resolution: | Keywords: AccountManager
-----------------------+----------------------------
Comment (by rjollos):
Replying to [comment:10 astaric]:
> Can you try opening a report (or doing anything that saves some data to
a session). This should also update your Last Login time (if it is older
than a day).
>
> As far as I can tell from the trac code, it only updates last_visit time
when session data is modified (Session.save in trac.web.session). It is
updated when there is no record for the session in the database
(Session._new == True) and when session data is being modified and session
is older than a day:
> {{{
> if session_saved and now - self.last_visit > UPDATE_INTERVAL:
> }}}
> If user does nothing that changes session data, last_visit will not be
updated.
If I force the save of the session data, such as executing a //Custom
Query// like you suggested, the `last_visit` does update. So it seems the
problem may be isolated to login.
From the testing that I did with vanillia Trac, I observed that the //Last
Login// time updates when the user authenticates. It makes sense that
`last_login` should update when the user authenticates, right? You may
want to do some testing with Trac then, just to confirm what I was seeing,
that `last_visit` is updated when the user authenticates in vanilla Trac.
In the cases of testing with both Trac and Bloodhound, I've set the
`last_login` value to `0` by editing the database before the test (though
it wasn't necessary in Bloodhound because it always stays `0` unless you
do something to force the save of the session data). That was just to make
the situation reproducible and not have to worry about the
`UPDATE_INTERVAL`.
Yesterday I had instances of Trac and Bloodhound running side-by-side with
a debugger, and I was stepping through the code and trying to figure out
how the execution pathways differ. There were some significant differences
in the pathway through `Session.save()` such as `session_saved` not being
set to `True`, but mostly I didn't document what I was seeing well enough
before my VM froze and I decided to call it a night. After I finish
another task I could return to this debugging session.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/554#comment:11>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound issue tracker
