It's possible to view a user's last login time by going to the Admin panel and the User management page and then clicking on each individual user. But this is cumbersome if you want to block/delete users based on their last login.
Proposal
Show each user's last_activity_on and created_at as a sortable column in /admin/users.
Move the search and sort field below the filter tabs such as with issues - also move the New user button to be inline with the tabs - until lower breakpoints.
Add last_activity_on (oldest + recent) as sorting options
@markglenfletcher Yes, in the regular user list at /admin/users. There is plenty of real estate to add a couple of useful sortable columns, but last login would be the most useful for user management.
I agree that this would be nice to have, but I'm not clear on the use case or problem this is really solving just yet 🤔@jwoods06, when do admins typically need to do this?
@jeremy_ Usually every year around renewal time (or even quarterly for true-ups) an admin will take a look at their user count and see if there are users they can prune based on their last login into GitLab.
Additionally, some folks are having to use the db-console to writing their own scripts to generate a simple "last login" report. We can make a lot of admin's lives easier with this type of functionality.
This might be a good candidate for ~"Accepting Merge Requests"? It looks like we can sort admin/users by earliest/latest login time, so it might be just a matter of surfacing this. 👍
Is it about just adding last sign in time as a string?
If yes, then where to put it (above/below/right/left)?
Or is it about adding a sortable column to the list?
The description proposes a sortable column which, I think, requires some UX work here as we don't have right now a table on the /admins/users page and thus we don't know how it really should look like to fit the current design/UX principles.
I think you're right on. I'll set this one as ~"Accepting Merge Requests" when UX has had a chance to provide some guidance here. Pinging @sarrahvesselov on that.
Thanks, @blackst0ne and @tauriedavis. We'll open this one to the wider community after we know how to present this.
Jeremy Watson (ex-GitLab)changed title from Display last login and created at for users in /admin/users to Display last login and created at datetimes for users in /admin/users
changed title from Display last login and created at for users in /admin/users to Display last login and created at datetimes for users in /admin/users
It looks like we already have sorting options in the Admin Users table to be able to sort by sign-in date as well as the user's creation date, so do we need the columns to actually be sortable? Or just displayed?
So from a UX perspective we just need to determine whether we display this login/creation timestamps as columns or format it differently. Otherwise, it looks like this is just a matter of printing out that information in the table.
My only concern is more on the backend side of things as I'm unsure if there will be any performance impact in fetching said timestamps, but that's because I'm unfamiliar of the database tables and whether acquiring said data would require JOINing other tables.
I think we'd just display the timestamps. As you pointed out, we can already sort with the dropdown, so it's just a matter of figuring out how we want to display this info.
@lmcandrew, do you have any thoughts on whether or not we need some backend work here? If so, it might be a real challenge to get to this issue. 😞
From looking at the API documentation it looks like we already return last_sign_in_at and created_at for a User. If I've understood the requirement correctly and this is the information required, then there shouldn't be any further backend effort.
@lmcandrew should this be followed up in a separate issue?
Yes, I think so. I will await a response from @helgi.gunnarsson to get a bit more context. I guess this doesn't block this Issue, but will be good to fix.
@lmcandrew I was trying to manage my inactive users and one had last_sign_in_at in July (in /admin/users/userid), but according to his profile page he pushed to a project in October.
He is probably an outlier, not that many that rely so much on their USER+PTA for git commands, but this possibility makes it harder to identify an inactive user through the the web gui.
last_activity_on tracks CLI and SSH git activity pretty well. The only thing I've seen that it misses is page views with an old but valid login session.
last_activity_at is deprecated. last_sign_in_at only tracks logins for web, and doesn't include page visits with an existing valid session.
Yeah, I think last_activity_on is a more useful timestamp than last_sign_in_at and I'd rather see a user's specific last activity date than their last login date.
But then again, maybe seeing both might be useful... if they have a more recent last_activity_on and a much older last_sign_in_at, then it might be indicative that they are using git (to push & pull), but not GitLab itself. There may be value in that distinction.
I agree that we should probably use last_activity_on here, as it's the best attribute we currently have that covers how active a user is. current_sign_in_at may not be reflective, since it only updates on a user entering credentials at a login screen and doesn't count existing sessions.
If the goal is "inactive user management" then login timestamps seem to hold little value since the session can live on for a long time and other activity can be performed without that timestamp being updated.
I just need a secure way to block users that have not been using the product.
For the UX, we can add the Created on and Last activity dates as columns in each row. For that, we need to add a table header to the list, in a pattern similar to the Pipelines page:
@dennis does this proposal sound doable or would it require a refactor of the rows?
In addition to this, how about sorting? We currently sort by oldest/most recent sign in, we should change this to oldest/most recent activity. We already have sorting for created_at, so that's solved.
In addition to this, how about sorting? We currently sort by oldest/most recent sign in, we should change this to oldest/most recent activity. We already have sorting for created_at, so that's solved.
Nice catch. We would have to change the options in the dropdown:
@dennis does this proposal sound doable or would it require a refactor of the rows?
We would have to refactor the template a bit, because it's not currently using a table:
I don't anticipate it significantly more effort though, however it does lead me to a question: how does this look on smaller breakpoints? Do we hide these additional columns? Or do we give them different treatment so they remain visible on said smaller breakpoints?
Nice catch. We would have to change the options in the dropdown:
Are we sure we want to change these options? Or should we just add two additional options for "activity" to the dropdown? Someone could still want to segment or filter by both properties?
Are we sure we want to change these options? Or should we just add two additional options for "activity" to the dropdown? Someone could still want to segment or filter by both properties?
Adding two additional options is fine. Let's just do that, since it doesn't remove an option that users might already be relying on.
I don't feel particularly strongly about it, but I'm just not crazy about being able to sort a table by a dimension I can't actually see.
Do we hide these additional columns? Or do we give them different treatment so they remain visible on said smaller breakpoints?
@dennis and @jeremy do you have any further thoughts on the above? IMO I'd suggest hiding the two new columns on smaller breakpoints due to the real estate required to display the full table.
EDIT: Else, after looking at how the table is handled for pipelines, we can easily have the full table displayed as long as we don't mind having users scroll horizontally in order to see all the information and reach the action buttons.
Jeremy Watson (ex-GitLab)changed title from Display last login and created at datetimes for users in /admin/users to Display last activity and created at datetimes for users in /admin/users
changed title from Display last login and created at datetimes for users in /admin/users to Display last activity and created at datetimes for users in /admin/users
@jeremy the value for last_activity_on returns a formatted date such as 2019-01-07 where created_at returns the full timestamp (2019-01-07 11:17:53 UTC) which can be converted to exactly match the example in the design. Are you happy with the last activity not having a time, or should we address that?
@blabuschagne: yeah, thanks for pointing that out. I'm aware that last_activity_on doesn't provide a datetime, it's totally fine to simply display the date.
Ah, good point. I'm not crazy about showing it one column and not the other, so I think we can strip the time out of the datetime for created_on. I don't think it's particularly important in this view; the problem we're trying to solve is to give admins information on when users have joined and when they've been using GitLab, and I don't think the time is a critical part of being able to answer that.