NEW: API for mass-disabling of idle users

[mrsimpson]

Partially Closes #9838

tl;dr

curl -H "X-Auth-Token: ${AUTH}" \
     -H "X-User-Id: ${USER}" \
     -H "Content-type:application/json" \
     ${HOST}/api/v1/users.deactivateIdle -d '{"daysIdle": 90}'

Motivation

Users which are not really using the system anymore for many reasons are a pain to operators: They complicate administration, but especially are a concern with respect to security.
This includes users who have not logged in to the application for a certain period of time as well as users which have been created long ago without ever using the system.

What this adds

This PR brings an API for deactivating idle users. The consumer of the API can provide criteria for selecting the users based upon which they shall be deactivated.

Implementation concerns

• Though not explicitly requested, there's the option to optionally pass a role so that you can have more strict checking for different roles, such as { "role": "admin", "daysIdle": 30}
• I decided to re-use the existing method to set users inactive though it's not mass-enabled. I assume it's not a task which is performed with a high frequency.
• Users collection shall have an index on role as well as lastUpdated. So I assume good performance for the query itself.
• Since this majorly is a database function exposed via an API and since I don't know how mocking of the DB is done in RC nowadays, I did not implement a test. Let me know if there's a way, then I'll be happy to do this too 🤓

[mrsimpson]

@geekgonecrazy we talked about this some time ago, here is the PR

[sampaiodiego]

I wonder if we should have this as a cron job instead of an endpoint that someone needs to call.

[mrsimpson]

@sampaiodiego sure there should be an option for a job, but this (c/sh)ould be in addition to the API.
As I wrote in #9838

I'll just start implementing an API to deactivate users which have been inactive for a longer time.
This is kind-of an intermediate step to automatic deactivation which requires some scheduler. This could be added as a second step

I wanted to keep the PR as small as possible, better add a second one.

[geekgonecrazy]

I can see the use case for both cron job and maybe just a one off.

I'd say logical next step for someone in future would be a follow up PR adding options for cron job

[mrsimpson]

Testing documentation

Setup

Deactivate idle users

Omitting the optional parameter to deactivate users

• the idle user has been deactivated
• the active user has not been deactivated.
• the never-logged-in user has also not been deactivated since it was just registered.

Deactivate idle guests

[claassistantio]

All committers have signed the CLA.

[rodrigok]

@mrsimpson and @rsjr I was reviewing this PR and since a had too many changes to request I decided to create a new PR with my proposal for this:

#16849

Idk if you want to update this one based on my PR or if we could close this and merge my one.

I did some code improvements and changed from the method call to disable user by user to a model method (replacing the find method) to update the users and set as inactive.

[mrsimpson]

Closed in favor of #16849 .
@rodrigok : Understood.

[RaNd250]

Since never logged in users don't count as "idle", is there an option to deactivate account which have never logged in ?