Automatic Deactivation of Users

[srenault-meeds]

Rationale

People once activated on the platform are not deactivated automatically. Platform administrators have to deactivate it manually.
They can use the analytics to check if users are actually active on the platform.

Yet, it implies admins to think about it and mostfully, people are still activated on the platform while they are no more active users.
This proposal aims to help admins to have a clean list of users, thanks to an automatic deactivation of users once not identified as active.

1. Functional Requirements

Top User Stories

Deactivate account once it is non active anymore

Once the user does not access the platform (login or connect) for xx months:

• xx being a property that can be configured,
• 6 months being the default value

Then the user account is deactivated.

In addition, it must be possible to specify which group members would be deactivate in the properties conf (no UI).

Allow to use analytics to check account activity

Check current operations for user creation, user activation, user deactivation to monitor activities on account.
This is tracked when the account is created, activated, deactivated using:

• UI option (add, activate, deactivate)
• File importation
• Automatic deactivation

Create User

• Current case:

  • operation: create user
  • Module: organization
  • Timestamp
  • isenabled
  • identity (created user)
  • Social: User ID (user who does the action)

• Expected:

  • Operation: Create User Account
  • Module (no change)
  • Timestamp (no change)
  • Status (isenabled)
  • User Account: (created user)
  • Social: User ID (creator of the account)
  • Source: UI, File Importation, User provisioning / LDAP / Selfregistration / on-the-fly registration

Activate / Enable User

• Current case:

  • operation: enableUser
  • Module: organization
  • Timestamp
  • isenabled: true
  • identity (account deactivated)
  • Social: User ID (user who does the action)

• Expected:

  • Operation: Enable User Account
  • Module (no change)
  • Timestamp (no change)
  • Status (isenabled)
  • User Account: (user account been enabled)
  • Social: User ID (user who update the account)
  • Source: UI, File Importation, User provisioning / LDAP

Deactivate / Disable User

• Current case:

  • operation: enableUser
  • Module: organization
  • Timestamp
  • isenabled: false
  • identity (account deactivated)
  • Social: User ID (user who does the action)

• Expected:

  • Operation: Disable User Account
  • Module (no change)
  • Timestamp (no change)
  • Status (isenabled)
  • User Account: (user account been disabled)
  • Social: User ID (user who update the account)
  • Source: UI, File Importation, Automatic Deactivation

Impacts

Gamification

N/A

Notifications

N/A

Analytics

Review current operations for user creation, user activation, user deactivation to monitor activities on account

Unified Search

Ensure deactivated people are not searchable

2. Technical Requirements

Expected Volume & Performance

A minor change on User Entities is expected in order to store the source of user creation. In analytics, some additional information has to be added.

Security

The creationSource field of User entity has to remain readonly, even when importing users through CSV.

Configurability

The Cron Job of Users Automatic deactivation has to be configurable through the property: ${social.UserAutomaticDeactivationJob.expression:0 15 23 ? * *}. Note that the default value is set to execute the job only once a day.

All inactive users, will be deactivated. The users will be considered as inactive, when they didn't login to the platform since 6 months at least. This default value of period will be configurable using the property ${social.user..inactive.period.days=180} (180 days).

Upgradability

No data upgrade is needed. The default value of Source should be blank for existing users.

Feature Flags

N/A

3. Software Architecture

Security

The source User field should be in readonly mode and set only on User Creation. Thus, when mapping a user while updating it, the creationSource field should be ignored.

Access

N/A

Services & processing

A cron Job will be added in order to check periodically for Inactive users. The method org.exoplatform.services.organization.idm.UserDAOImpl.findUsersByQuery(Query, UserStatus) will be used to request the inactive enabled users. The users will be disabled and a new Field inside the User will be added in order to indicate that the deactivation was made automatically (attribute automaticDeactivation set to true).

For the User creationSource attribute, a new DTO attribute has to be added, same as originatingStore. This will allow to preserve permanent access to the information of originating creation source. This information will be used in analytics Listener in order to provide this information in collected statistics.

[srenault-meeds]

To check please @margondicco @Julien-Dubois-eXo

[margondicco]

Hello

just one feedback for analytics

Account: [Profile Name] =>
I prefer to display the user ID (with the first name and surname attached)

example of the expectation

[srenault-meeds]

yes

[margondicco]

Hello Go fonc

[boubaker]

Ready for spec review by DAO members (eXo: @rdenarie )

[rdenarie]

Hi.

On functionnal side, when there is an automatic deactivation like we are preparing, we generally have a mail sent few days before the deactivation.
This mail says somethink like :
"Your account will became inactive in few days. If you want to keep it active, connect to the platform.
Without action from your part your account will be deactivate on ..."

Is it something we have plan in a future improvment ?

On technical side, ok for me

[srenault-meeds]

Is it something we have plan in a future improvment ?

Indeed, we have identified with Morgan items that could be added in the future:

• email notification one week ago
• notification for admins about deactivation
• access to a dashboard in admin site / users management to list users recently deactivated

However, we wanted to make this first implementation as simple as it could be to avoid working too much. We will see if end-users will confirm or not to have more options (notifications, dashboard for example).