Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    Projects Groups Snippets
  • Sign up now
  • Login
  • Sign in / Register
  • F foodsharing
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 355
    • Issues 355
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 26
    • Merge requests 26
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • External wiki
    • External wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • foodsharing-devfoodsharing-dev
  • foodsharing
  • Issues
  • #956
Closed
Open
Issue created Aug 21, 2020 by Alex@alex.simmMaintainer

Persistent sessions are a problem for the last login date

Summary

Since !1585 (merged) people can stay logged in for a long time. The 'last login' timestamp is however only updated on login and therefore not really valid in any case. Some functions depend on that value and might assume that users are not active anymore even though they are.

Possible fixes

Maybe the nightly maintenance script could check all open sessions and update the login date for those users. Another option might be to use the websocket from the message API.

Assignee
Assign to
Time tracking