Reactivate User

Deactivated users are users which were formerly part of Karl but which no longer have active logins in the system. The notion of deactivation replaced earlier notions of deletion, in order to solve the problem of community content owned by deleted users. Under this specification, users which were previously deactivated may now be reactivated. Upon reactivation, no email notice of any kind is sent. They won't be re-attached as members of communities they were once in. Thus in the case of a private community, they might be the owner of a piece of content they can't access.

If they click the Join button, they can ask the moderators to get back into the community, and it will then be as if nothing changed from the previous de-activation.

There are several paths by which a previously deactivated user may be reactivated:

A) When an administrator edits the profile of a previously deactivated user, there is a link at the bottom of the form which says 'Reactivate User'. This link is in the same place as the 'Deactivate User' link when editing an active user. When the user is reactivated, a password reset procedure is initiated for that user. The user receives an email message with a link to reset their password.

B) When using the Admin UI to add users by uploading a CSV file, the administrator will see a new checkbox: "Reactivate users." When this box is *not* checked, if the CSV file contains a user id or an email address which belongs to a previously deactivated user, the operation will fail and the administrator will see a message informing them that the CSV file contains a user id or an email for a previously deactivated user. The administrator will be invited to check the "Reactivate users" checkbox if they intend to reactivate those users. When the "Reactivate users" checkbox *is* checked, users will be reactivated if a CSV row contains a user id or email address for a deactivated user.

C) OSI only. When, for a staff user, the GSA sends: <inactive>0</inactive> in the xml for an inactive user, that user will be reactivated

A number of ancillary user interface improvements will also be made to improve administrative workflow and reduce user confusion:

1) Permissions will be altered for deactivated profiles such that they show up in searches and are editable by members of KarlAdmin and KarlUserAdmin. Deactivated users will still be hidden in searches by non-administrative users.

2) The title used to display the name of deactivated users will now have the text: "(Inactive)" appended. Thus, when viewing a profile directly or seeing it listed in a search it will be readily apparent that the user is inactive, eg: John Doe (Inactive).

3) Currently if an administrator attempts to add a user to Karl and the user id or email address belong to an inactive user, the operation simply fails without a good explanation to the administrator that the user is in the system but inactive. In this case, the administrator will be informed that the user is in the system but was previously deactivated and provide a link to reactivate the user.

4) When a moderator uses 'Add Existing' view to add members to a community, deactivated users will be hidden.

5) When a moderator uses 'Invite New' view to invite members to a community, an email address for a deactivated user will cause a validation error. The moderator will see a message explaining that the email address belongs to a deactivated user and that a system administrator will need to reactivate the user before they can add the user to their community.