Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mark and remove inactive users from a group #868

Closed
tiltec opened this issue Feb 7, 2018 · 7 comments

Comments

Projects
None yet
4 participants
@tiltec
Copy link
Member

commented Feb 7, 2018

As mentioned in #853, it would be nice to remove inactive users from a group:

due to inactivity: notify and mark as inactive after 1 month (grey out in member list), notify again after 2 months, remove from group after 3 months

Questions were raised by @djahnie

  • What counts as activity? (read or write access, imho read is enough)
  • What is the process and what are the timeframes?

I think activity should be counted per group and read/write access should both be counted as activity. It will therefore be possible to get removed from a group while being active in another one. It will also be possible to stay active by just visiting the group from time to time.

@djahnie

This comment has been minimized.

Copy link
Member

commented Feb 20, 2018

I agree on your definition of activity and that it has to be counted per group.

What are the first steps to implementing something like this? I guess a new field in the database that has the binary choice of being set to 'active' or 'inactive' is needed, as well as some code, that counts the time since the last activity of a user. This is more of a backend task, am I right?

(In case this is not obvious, I'm trying to find more starter tasks...^^)

@nicksellen

This comment has been minimized.

Copy link
Member

commented Feb 20, 2018

This also ties a bit into my ponderings on how to record activity in general (so it's clearer which people/groups are actively using it) - my ponderings led me to think in terms of 3 levels of activity:

  • registered user (signed up, but do nothing)
  • online user (they log in, click around)
  • active user (they do pickups!)

Maybe it's also useful to distinguish between users that are active online (writing messages, editing things, etc) and passive ones (just click around a bit), but maybe not...

Historic data is better stored in influxdb I think and exported periodically, but the application also would/might/should have some historic data too, where it makes sense for the logic of the application (I think the application should not read from influxdb).

Perhaps a storage format for inside the application would be an activity table and record into time buckets per user+group, e.g. recordActivity(user_id, group_id, time_bucket, activity_type) where time_bucket might be a day , and activity_type might be online|offline. the data could be sent to influxdb db at the same time, then the application can delete from the activity table when it makes sense for the application logic (e.g. you only actually need to know the last activity).

So, actually, rethinking as I write, if we need to only know the last activity then could store that directly in the user/group join table (last_online_activity_at, last_offline_activity_at), and write to influxdb as before.....

... or even just repurpose the history table, and check when their last activity was (although that does not record things like logging in, but could (and just filter it from the normal view), but could end up with too much data in there that we don't really need.

The activity table could have counters for each time bucket row too if we wanted to keep track of how much activity too, not just whether there was some.

Seems enough thoughts for now.

@djembejohn

This comment has been minimized.

Copy link

commented Feb 27, 2018

@tiltec and I have been looking at this in a bit more detail this morning. We decided to implement the simplest useful answer to the problem which was to add a single "last_seen" field to the GroupMembership model. In terms of the user, the field is intended to represent the last time a user had used Karrot (via a browser or the app) to actively view data associated with a group.

Our initial implementation was to use the current_group field in AuthUser. This worked to some extent, however it was only updated when we use the 'Change group' menu option on a browser. (We also noticed that it is possible to open two different groups in two different browser tabs, which may lead to some issues but didn't seem to break anything.)

We discussed a few options:

  1. Add a hook in the backend which checks if read_access permission has been requested on a group and then update last_seen at that point. There are two problems with this. First, updating the DB when only a request has been made is probably not a good idea. Second, a future frontend implementation might cache several groups' data which would make it look like a user had done something in a group when they hadn't.
  2. Change responsibility to the frontend to call a function in the backend to report that a user had done something in a group. We would implement a post-function in the backend for the frontend to report that a specific user had accessed a group.

Option 2 probably resolves the potential problems from option 1, but might have some new issues?

@tiltec

This comment has been minimized.

Copy link
Member Author

commented Feb 27, 2018

The approach (2) still seems good to me, I'd say it's worth a try.

@djembejohn

This comment has been minimized.

Copy link

commented Feb 28, 2018

Option 2 is now working and has a mark_user_active endpoint.

We now envisage the following tasks:

  • Implement calling the mark_user_active endpoint into the frontend

  • Add a boolean field "isactive" to GroupMembership (default=True) which is set to True whenever the endpoint is called

  • Write a script which looks for inactive users and sets the isactive field to False after a time period, and removes inactive users after a second time period

  • Write an email template for users who have been flagged as inactive to warn them they will be removed from the group / tell them they have now been removed

  • Implement greying out of inactive users in the frontend

@tiltec

This comment has been minimized.

Copy link
Member Author

commented Mar 11, 2018

The current backend implementation marks a user as inactive_at = <date> after 30 days of not visiting the group and sends out an email to the user.
The group API has a field active, which is False when the user is inactive.

#957 marks inactive users in the member list.

Future improvements:

  • only show active members in the group member count (GroupGallery)
  • remove long-time inactive users from the group yunity/karrot-backend#528
@djahnie

This comment has been minimized.

Copy link
Member

commented Mar 28, 2018

We decided to wait for feedback for the current implementation to find out if the automatic removal is actually needed right now.

@djahnie djahnie closed this Mar 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.