Track user activity within a persistent session

Created on 7 January 2013, almost 12 years ago
Updated 8 September 2024, 2 months ago

Hi, and first of all thanks for creating this module - you just saved me a bunch of time :) One of the challenges I have that I am looking to solve is as follows.

- The module adds an entry via hook_user_login / hook_user. This captures login history details when the user enters credentials and creates a brand new session.
- The maximum length of a Drupal session is controlled via settings.php, specifically:

ini_set('session.cookie_lifetime',  2000000);

- The cookie lifetime is 2 million seconds, or just over 23 days.


So... assuming my session table is not flushed out and the users continue to use the same browser, I'm only going to see their login activity once every 23 days since that's when they are forced to re-authenticate. What I want to do is to keep the long cookie lifetime but more closely track activity. This will involve measuring the length of time between activity and capturing a new 'login' event. For example, let's say a user uses the site at 8AM on a Friday for an hour, then comes back Friday night at 6PM. I'd want to track each of those as separate logins even though neither of them would hit the hooks because an actual authentication event is not taking place.

One of the primary reasons I want to capture this is so I can map the time of day and week when each user is most likely to be using the site, and then use that metric as an input to my email and other notifications so I send updates and digests when it's optimum for the recipient to see it and come back to the site.

Thoughts? Do any of you share my interest in this feature? I'm happy to contribute code to implement it but not before understanding if my code has a shot of being accepted and talking through design with the maintainers. Thanks!

✨ Feature request
Status

Needs review

Version

2.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States rjbrown99

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡©πŸ‡ͺGermany mkalkbrenner πŸ‡©πŸ‡ͺ

    We facing the same issue. Rather than a login history we need an activity history. Ideally one entry per day if the user does anything.

  • Assigned to mkalkbrenner
  • πŸ‡©πŸ‡ͺGermany mkalkbrenner πŸ‡©πŸ‡ͺ

    I implemented a protoype. I'll polish it a bit and upload a patch here.

  • Status changed to Needs review about 1 year ago
  • πŸ‡©πŸ‡ͺGermany mkalkbrenner πŸ‡©πŸ‡ͺ

    This patch adds the feature. It is mostly complete.
    If it gets accepted, I could add a a settings page for the new settings. But you can already adjust them via config management or overwrites.

  • πŸ‡©πŸ‡ͺGermany mkalkbrenner πŸ‡©πŸ‡ͺ

    Forgot to handle activity_log_interval: 0 to turn activity logging off.

  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 10.1.x + Environment: PHP 8.2 & MySQL 8
    last update about 1 year ago
    Composer require failure
  • Issue was unassigned.
  • πŸ‡©πŸ‡ͺGermany mkalkbrenner πŸ‡©πŸ‡ͺ

    The patch is against 2.x. Unfortunately the 2.x branch is not enabled for testing.

  • πŸ‡©πŸ‡ͺGermany mkalkbrenner πŸ‡©πŸ‡ͺ

    Here's an adjusted version of the patch against 2.x-dev.

  • πŸ‡©πŸ‡ͺGermany mkalkbrenner πŸ‡©πŸ‡ͺ

    Another adjustment to resolve the conflict with in the update hook.

  • Nice work @mkalkbrenner, serving my particular use case perfectly with minimal config and disruption

  • πŸ‡¨πŸ‡¦Canada avo webworks Ottawa, Ontario, Canada

    Wonderful patch #17 works well and this is a great addition to the module. Thank you for your work @mkalkbrenner!

    Great if this can be committed to the module.

  • πŸ‡΅πŸ‡ΉPortugal jcnventura

    So, camslice and avo webworks, do you still believe that this still needs a review? What I read from your non-change of status is that you tested, and think it works, but you consider that you didn't test it completely.

    Please refer to https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-... β†’ for what the status field in an issue means.

  • πŸ‡¨πŸ‡¦Canada avo webworks Ottawa, Ontario, Canada

    Hello @jcnventura.

    This patch works for me but I am hesitant to set the patch status to "RTBC" as described in the link you had me refer to I quote:
    "Setting an issue to this status is a judgment call: if you have thoroughly tested and reviewed the patch and believe it is ready, you may change the status. If you are unsure, the status should not be changed. Simply add the findings of your review to the issue.

    Remember that even if one or two community members believe an issue is ready, that doesn't necessarily mean that it will be committed. If it is not, it can be reverted to an earlier status. The better the reviews, the more likely the code will actually get committed."

    Personally, it would be great if we had a few more folks test before marking it RTBC...

    Having said that this patch is a fantastic addition to the module in order to also track sessions.
    Thank you for this module and the work folks have done on it!

Production build 0.71.5 2024