Skip to main content
Version: 6.0

Case Manager 6.0 Upgrade: User Management

Case Manager 6.0 features a few major changes to the users and workgroups in the system. The following aspects should be taken into consideration when upgrading a client.

tip

Review the new functionality and changes to User Management here.

Workgroup Structure​

The workgroup structure changed in version 6 of Case Manager:

  1. In previous versions of Case Manager a team could not consist of both users and other teams on the same level. This restriction has been removed: a user and team can now appear on the same level in the hierarchy.
  2. The Default Workgroup has been renamed to the Organization Workgroup.
  3. As in Case Manager 5, a user entry has a unique workgroup associated with it. Both the user object and the associated (user) workgroup have the same fields (such as name, surname, etc). This information is now synced between the two objects. That is when, for example, the name is updated on the user object the name field will also be updated in the associated workgroup object.
  4. The display name of a user in the system is now generated by concatenating the name and surname of the user. There no longer are options of formatting the user display name.
  5. Because of the changes in the workgroup structure rules, there is a small chance that with upgrades some users previously hidden will now be visible, and users previously visible will now no longer be visible. We tried to address most of these in the upgrade, but we’ve seen especially with older databases there may be scenarios where this still occurs. Therefore, during the upgrade confirm that the user visibility is still as before the upgrade. If not, you’ll have to analyze based on the rules stipulated in this document why that is the case and fix these problems manually.

Visibility and deleting​

Case Manager 6 now supports a soft delete of users and teams. The following changes were made:

  1. The IsActive property on a workgroup object has been replaced by a three-state indicator of the object state: namely Active, Inactive, and Deleted.
  2. Workgroups should only be deleted using the User Management tools (accessible from either Case Manager or the Configuration Tools). When deleting a user a list of actions will be presented to the user deleting the workgroup. These actions ensure that no work, workflow, settings, queues, security, or any other association remain on the deleted workgroup other than for historic record keeping.
  3. Currently, because of the complexities of the delete actions, workgroups cannot be deleted in bulk. The deletes will have to be performed one by one. After an upgrade it may be worth looking into which workgroups should be deleted.
  4. Deleted workgroups will no longer appear in lists - even when a “View inactive” option is enabled. These deleted workgroups can, however, be viewed from the System and Deleted Users action in the User Management section. A user can be restored from here, but all the associations and setup removed during the delete process will not be restored.
  5. Note that the username will remain on deleted entries. One would therefore not be able to create a new user profile with the same username as a deleted user.
  6. The Inactive state is now enforced in the hierarchy. These rules are also enforced when workgroups are moved by drag-drop in the User Management.
    1. All subteams and users will be made Inactive when a team is set to Inactive.
    2. When a user/team in an inactive team is set to Active, the parent team will also be set to Active.
    3. The Organization Workgroup is always Active.

Login changes​

As part of the improvements in User Management we also revamped our login processes.

  1. All users now have a unique username. This can be edited in the User Management section. During an upgrade a username is generated for all the existing users: in general in the format {name}.{surname} . Please confirm that the format of these usernames seem in order without space and all lowercase letters.
  2. All references to VoyagerNetz in workgroups names are renamed to Case Manager.
  3. A user can log in either by selecting the user from a list (as in version 5) or by typing the username. The settings on the login form can be used to change the mode of login.
  4. In the Case Manager settings the preferred login mode can be set for the site.
  5. The password encryption has been improved. Please ensure that all custom applications making use of login use the standard login controls to ensure the correct method is used.
  6. The login details (username and password) for console applications can now be specified as command line arguments. This will influence especially scheduled tasks (such as the Daily Maintenance Runner). You can make use of the -help argument for more information on the supported command line arguments for login.

Support Users​

We want to standardize the system and support users. With the changes to users mentioned above there has been a few additional changes for these users:

  1. A user license is no longer required to log in with a system/support user.
  2. A system/support user will no longer appear on the user list during login. Only login with username is supported. Note that, by default, usernames of system users start with a full stop character.
  3. These users are not assignable to a parent team. They will also not appear in the workgroup hierarchy. In the User Management they can only be accessed via the separate System Users actions.
  4. Since the system users do not appear in the Workgroup hierarchy, it will also not be possible anymore to assign work to these users. There seems to be a few different standards for these support users.

Security Roles​

Security Roles were introduced in Case Manager 6 simplifying the management of user rights in the system tremendously. Of course, this is only the case when the site makes effective use of the functionality. With a new implementation this should not be a problem, but with existing clients they may need assistance in setting up appropriate roles and assigning them to the relevant users.

  1. During an upgrade, the old Security Templates are migrated to Security Roles. Since we don't have a record of which template was assigned to which user, we cannot migrate the assignments. This will have to be done by the administrators manually.
  2. Case Manager supports user security rights either by Security Role, or right assigned directly to the user (as with version 5). As implied by the previous point, all existing users are migrated to the directly-assigned security approach.
  3. Roles can be assigned to users in bulk from the Security Roles section in the Configuration Tools.
  4. There have been a few changes to the security rights as well. Old rights no longer applicable have been removed, and a few new rights have been added. Please review the available security rights. You can also now right click on a security right to see all the users and roles with the right assigned. One example of a change of rights is the introduction of the User Administrator and Workflow Administrator right which allows a user access to the User Management, and workflow-related setting respectively without requiring the System Administrator right.

Team Diary View​

On the Electronic Diary, next to the selected level, an additional button is available to include/exclude the work from all subteams and -users. In version 5, selecting the dairy level to that of a team, you could only see the work directly assigned to the team as the workgroup. The diary now supports seeing all the work in a team as the entire branch in the workgroup hierarchy (that is, including the work assigned to the subteams and -users).