Every user account in the imc Learning Suite has an authentication status, "Active" or "Passive", that decides whether the user has access to the platform. Deletion ends an account for good, either by anonymising the record or by removing it completely.
At a Glance
|
Status |
Meaning |
How It Is Reached |
Can the User Log In? |
|---|---|---|---|
|
Active |
Account in normal use; authentication status "Active" |
Account creation; after self-registration with an activation workflow, only once the activation link has been clicked |
Yes |
|
Passive |
Account deactivated (deregistered); the record remains in the system |
Automatic passivation, scheduled deregistration, the starting account of a merge, a deletion request with delay, or an administrator |
No |
|
Locked |
Account temporarily locked after repeated failed logins; local authentication only |
Reaching the maximum number of failed login attempts |
No, until the lockout ends (30 minutes by default) or is reset manually |
|
Deleted |
Record anonymised or completely removed |
Deletion by an administrator or by the "DeleteUsersJob" |
No |
Active and Passive Users
The status is stored in the personal attribute "Authentication status" with the values "Active" and "Passive". Passive users are also referred to as deactivated or deregistered. Administrators can change the authentication status in the user profile, for example to set a self-registered user to "Active".
A passive status has further effects. On courses with the meta tag "Automatic cancellation of inactive users" (ID 11813), the job "CancelInactiveUsersJob" cancels the user's non-completed enrolments. With "Show Active Group Members Only" in Configuration Manager - User, passive accounts are hidden in the user lists of the group management.
Automatic Passivation
Two settings on the "Access and Security" tab in Client Administration set users to passive automatically. The scheduled job "UserTerminate" checks the termination dates and sets users to passive as configured in the client.
After the Last Login
"Passivate all users x days after last login" sets users to passive who have not logged in for the configured number of days. A user who has never logged in is also set to passive once this period has expired since the account was created. With 90 days, for example, a user whose last login was 90 days ago or less stays active, and a user whose last login was longer ago is set to passive. A setting with the same name also exists in Configuration Manager - User.
After the Last Forecasted Personal End Date
"Passivate User x days after last forecasted personal end date" sets users to passive who have had no active enrolment for the configured number of days. An enrolment counts as active while the current date is before its forecasted end date. Without a value, users of the master client are not passivated on this basis. The last forecasted personal end date is the latest of these dates across the user's courses and learning paths:
-
Date-dependent course, status "Enrolled": end date of the course
-
Date-dependent course, status "In progress", "Passed" or "Failed": personal end date
-
Duration-of-use course, status "Enrolled": enrolment date plus duration of the course
-
Duration-of-use course, status "In progress", "Passed" or "Failed": personal end date
The calculation considers the user's master client. A user who has never been enrolled on a course or learning path since creation is set to passive once the period has passed.
Both passivation settings can deactivate large numbers of users at once when the threshold is reached. Review the values carefully and consider the impact on all users of the client before enabling or changing them.
Scheduled Deregistration
The "Schedule" function in the User Manager limits a user's access to a specific time interval and determines when the user is deregistered. "Termination Mode" in Configuration Manager - User defines which deregistration types are available. With "Manual", an administrator deactivates the user on the date in the profile attribute "deactivationtime_proposed", and the profile shows a yellow square if this does not happen. With "Automatic", the user is deactivated on that date. The option "None" is always available, so that the user is never deactivated by scheduling.
Denial of Access
Denial of Access locks a user account after a defined number of consecutive failed login attempts. By default, a lockout lasts 30 minutes; the number of attempts and the duration are set under "Number of attempts" in Configuration Manager - Security. Locked accounts appear in a list, where "Reset Selected Login Attempts" or "Reset All" lifts the lockout. A failed login always shows the same generic message, whether the login name does not exist, the password is wrong or the account is locked. Denial of Access only applies to local authentication; with single sign-on (SSO) or another external identity provider, the identity provider manages lockouts.
Deletion
"Delete" in the User Manager deletes the selected user. What happens to the record is set in the "Privacy Settings" on the "Access and Security" tab of the client:
-
"Type of user deletion": anonymisation, which keeps the learning history, or complete deletion, which removes the user's entire record
-
"Remove forum contents": replaces the user's forum contents with the placeholder "Content removed", regardless of the deletion type
-
"Delay the execution of deletion request by": delays the deletion by a number of months
-
"Delete User x days after deregistration": deletes a deactivated user after the configured number of days
An anonymised participant remains in participant lists as an anonymous entry. When two accounts are merged, the starting account becomes deregistered and possibly anonymised.
Delayed Deletion
If "Delay the execution of deletion request by" is greater than 0 and a user requests deletion or an administrator triggers it, the user is marked for deletion on today's date plus the configured number of months. From then on, the deletion cannot be triggered again, the authentication status is set to "Passive", and administrators can no longer set it back to "Active". The "DeleteUsersJob" finally removes all users whose deletion date has passed, either by anonymisation or by complete deletion. See Scheduled Jobs.
The "DeleteUsersJob" removes or anonymises data permanently, with no recovery option. Together with automatic passivation, "Delete User x days after deregistration" deletes inactive users automatically, so review both values together before enabling them.
Effect on Login
Active users log in with the authentication methods configured for the client. After self-registration with "Enable activation workflow for self-registration", users can only access the platform once they have clicked the activation link in the e-mail. Deregistration ends a user's access to the platform, so passive users cannot log in. A lockout blocks the login until it expires or is reset manually, and a deleted user no longer exists as an identifiable account.
How It Fits Together
When both passivation settings are configured, they are combined in this order:
-
The last login is checked first, and all users whose last login is older than the configured number of days are identified.
-
For these users only, the last forecasted personal end date is checked in addition.
-
A user is set to passive only if both periods are exceeded.
Example from Client Administration, with a login timeframe of 180 days and an enrolment timeframe of 365 days:
|
Last Login |
Last Enrolment |
Outcome |
|---|---|---|
|
180 days or less |
365 days or less |
User remains active |
|
180 days or less |
More than 365 days |
User remains active |
|
More than 180 days |
365 days or less |
User remains active |
|
More than 180 days |
More than 365 days |
User is deactivated |
After passivation, the privacy settings take over:
-
The user is passive and has no access to the platform.
-
Once the number of days in "Delete User x days after deregistration" has passed, the user is deleted.
-
According to "Type of user deletion", the record is anonymised, keeping the learning history, or removed completely.
Typical Scenarios
|
Goal |
Use |
|---|---|
|
Deactivate accounts that have not been used for a while |
"Passivate all users x days after last login" |
|
Deactivate users without any running training |
"Passivate User x days after last forecasted personal end date" |
|
Only deactivate users who neither log in nor have running training |
Both passivation settings together |
|
End a user's access on a known date |
"Schedule" in the User Manager with the termination mode "Automatic" |
|
Delete deactivated users automatically |
"Delete User x days after deregistration" |
|
Keep the learning history after deletion |
Anonymisation in "Type of user deletion" |
|
Give a grace period before a requested deletion takes effect |
"Delay the execution of deletion request by" |
|
Unlock a user after failed logins |
"Reset Selected Login Attempts" in Denial of Access |
|
Remove passive users from running courses |
Meta tag "Automatic cancellation of inactive users" with "CancelInactiveUsersJob" |
Hints & Tips
-
There is no switch that turns anonymisation off. It results from deregistration, the waiting time until deletion and, where configured, rules.
-
Anonymised or deleted users cannot simply be reactivated. It is therefore recommended to check the privacy settings before enabling them.
-
The number after "Anonymized…" is generated during deletion and is not the user's former ID.
-
If a manually set deletion date disappears on saving, registration rules have removed it. To resolve this, fulfil the conditions of the rule, delete the user manually, or have the rule adjusted.
-
Users who seem to be missing from reports or the audit log after a deletion or merge appear there anonymised or under the remaining user.
-
With SSO, check lockouts in the identity provider, not in Denial of Access.