Inactivate users to manage users with administrative commands
Overview
To use administrative commands to manage Profiles users, set their status to inactive.
Important: The commands in this topic are provided only as a last resort. They allow the administrator to modify the data associated with a specific user in the Profiles and application databases. User data is normally automatically updated from the repository using the Tivoli Directory Integrator scripts or the Profiles Administration API. The commands to update, activate, and inactivate users can introduce discrepancies between the application databases and the repository if not used carefully.
IBM very strongly advises that to avoid introducing discrepancies, check the data of the user in the repository prior to using these commands.
These commands should not be used to propagate directory ID changes. If the Profiles database contains an updated directory ID for a user, it will not be able to identify that user to other component applications containing an earlier version. These commands can be useful for propagating other profile updates.
If profiles in other applications remain out of synch after TDI or admin API commands have been issued, see Sync user data with administrative commands.
Configure IHS before attempting to synchronize data between the Profiles database, and other application databases.
We can manage users in Profiles to allow for situations in which employees leave the organization. For example, we can set a user's status to inactive, which allows you to reuse the associated email address and login details for new employees. We can also reactivate a user's status in situations where the user leaves the organization temporarily. For example, if a profile owner goes on sabbatical or personal leave, we can set his status to inactive and then reactivate the user's status when he returns.
When you set a user's status to inactive, that user's name is displayed in italic, gray text in membership lists, and their name is not returned in searches of the company directory. The inactive user's name no longer displays when we use type-ahead, and the person no longer receives email notifications from IBM Connections.
Access the Profile configuration
cd app_server_root/profiles/Dmgr01/bin
./wsadmin.sh -lang jython
execfile("profilesAdmin.py")
Commands
- ProfilesService.inactivateUser(String user_email_addr)
Inactivate the user with the specified email address.
After running this command, the user is no longer active in the system. The email address is removed from all member tables and the status of the user changes from active (0) to inactive (1). All the user's login values are removed from the login tables and the login values associated with the user in the PROFILE_LOGIN table are removed. An event is created in which Profiles propagates these changes to the member and login tables of all installed applications to verify the user's information is updated consistently across the application databases. The status of inactive users can be reactivated at a later time using...
ProfilesService.activateUserByUserId
For example:
ProfilesService.inactivateUser("john.smith@myco.com")
- ProfilesService.inactivateUserByUserId(String userID)
Inactivate the user with the specified user ID.
After running this command, the user is no longer active in the system. The email address is removed from all member tables and the status of the user changes from active (0) to inactive (1). All the user's login values are removed from the login tables and the login values associated with the user in the PROFILE_LOGIN table are removed. An event is created in which Profiles propagates these changes to the member and login tables of all installed applications to verify the user's information is updated consistently across the application databases. The status of inactive users can be reactivated at a later time using the ProfilesService.activateUserByUserId command.
The userID parameter is defined in profiles-config.xml by the lconnUserIdField tag. Default is guid, which is stored in Prof_guid in the profiles database. The values for Prof_guid must match the values for UserID.
For example:
ProfilesService.inactivateUserByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4")
- ProfilesService.activateUserByUserId(String user_external_id, updated_properties_list)
Activate user with the specified external ID with new properties, passed as parameters using updated_properties_list.
The user_external_id parameter is the unique ID defined in profiles-config.xml by the lconnUserIdField tag. Default is guid, which is stored in Prof_guid in the Profiles database. Default status is active.
Properties for updated_properties_list...
loginId The value stored in the PROF_LOGIN field in the EMPLOYEE table. logins The list of logins stored in the PROFILE_LOGIN table. displayName
directoryId (guid) The value stored in the PROF_GUID field in the EMPLOYEE table.
You should specify at least one of the properties that will allow the user to log in, and it must be specified using a name-value pair.
The status change and all property updates are propagated to all the installed IBM Connections applications.
Examples:
ProfilesService.activateUserByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4", email="jsmith@myco.com", loginId="jsmith")
ProfilesService.activateUserByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4", email="ajretired1@myco.com", logins=["alanjones1","ajonesRetired1"])
ProfilesService.activateUserByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4", email="speters_Retired1@myco.com")
- ProfilesService.updateUser(String user_email_addr, updated_properties_list)
Replace the existing properties for the user with the specified email address with new properties, passed as parameters using updated_properties_list.
The valid properties for updated_properties_list are:
displayName
directoryId (guid) The value stored in the PROF_GUID field in the EMPLOYEE table. loginId The value stored in the PROF_LOGIN field in the EMPLOYEE table. logins The list of logins stored in the PROFILE_LOGIN table. The list must be passed using the format: ["login1", "login2"]
The properties are all optional and are specified using name-value pairs. The updated values are pushed out to all the applications in Connections using a platform command.
For example, to update the email address and the login for the user john.smith@myco.com.
ProfilesService.updateUser("john.smith@myco.com", email="update_email@myco.com", loginId="updated_login")
To replace the existing list of logins with the new one, ("login1", "login2").
ProfilesService.updateUser("john.smith@myco.com", logins=["login1, "login2"])
- ProfilesService.updateUserByUserId(String userID, updated_properties_list)
Replace the existing properties for the user with the specified user ID with new properties, passed as parameters using updated_properties_list.
The valid properties for updated_properties_list are:
displayName
directoryId (guid) The value stored in the PROF_GUID field in the EMPLOYEE table. loginId The value stored in the PROF_LOGIN field in the EMPLOYEE table. logins The list of logins stored in the PROFILE_LOGIN table. The list must be passed using the format: ["login1", "login2"]
The properties are all optional and are specified using name-value pairs. The updated values are pushed out to all the applications in Connections using a platform command.
The userID parameter is defined in profiles-config.xml by the lconnUserIdField tag. Default is guid, which is stored in Prof_guid in the profiles database. The values for Prof_guid must match the values for UserID.
For example:
ProfilesService.updateUserByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4", email="update_email@myco.com", loginId="updated_login")
- ProfilesService.swapUserAccessByUserId(String userToActivate, String userToInactivate)
Associate the following properties of the external ID assigned to the person returning to the organization with the external ID used by the person before leaving the organization:
The displayName property is not changed; it is assumed to be the same.
Users can have access to the data associated with one or the other ID only. When you swap IDs to give a person access to the data associated with an old ID, he loses access to any data he created using the new ID. Run this command soon after the user returns to the organization to limit the amount of new data he can create and subsequently lose access to as a result of the swap.
Required parameters...
userToActivate Current user ID of the person before leaving the organization and had his user state set to inactivate. Data that was created by this person and associated with this ID exists in the Lotus Connections databases and you want the person to be able to regain access to it. userToInactivate New user ID that was assigned to the person upon his return to the organization.
Example:
ProfilesService.swapUserAccessByUserId("DRcuidk001retired13","DRcuidk001rehired25")
These changes are propagated across all the installed applications in Connections.
- ProfilesService.publishUserData(String user_email_addr)
Publish an update command to all the Connections applications for the user with the specified email address.
The command publishes the data currently stored for the user in the Profiles database (email, displayName, logins, directoryId). If one of the applications misses an update event for some reason and the incorrect email address or name is displaying for a user, for example, we can use this command to force all the applications to resynchronize their data.
For example:
ProfilesService.publishUserData("john.smith@myco.com")
- ProfilesService.publishUserDataByUserId(String userID)
Publish an update command to all the Connections applications for the user with the specified user ID.
The command publishes the data currently stored for the user in the Profiles database (email, displayName, logins, directoryId). If one of the applications misses an update event for some reason and the incorrect email address or name is displaying for a user, for example, we can use this command to force all the applications to resynchronize their data.
The userID parameter is defined in profiles-config.xml by the lconnUserIdField tag. Default is guid, which is stored in Prof_guid in the profiles database. The values for Prof_guid must match the values for UserID.
For example:
ProfilesService.publishUserDataByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4")
Parent topic:
Manage users when the Profiles application is installed
Related:
Specify the global ID attribute for users and groups
Configure IBM HTTP Server
Synchronize user data
Troubleshoot user data synchronization
Delete or inactivate users in the Profiles database
Sync LDAP with Profiles
Attribute mapping for Profiles