The Permissions property was relocated to Role components (new in Niagara 4), which are children of a new RoleService in the station. Instead of a User being assigned permissions directly, now you assign each user to one or more Roles. Permissions of those roles are “OR’ed” together to specify what privileges a user has on the categories in the station.

In order to migrate Users from AX to N4.0, while preserving their existing category permissions, note an N4 migration results in a separate Role created for each User—and named identically to that User.

Figure 21.   Station migrated to N4.0 has default “one-to-one” mapping of new Roles to existing Users

This one-to-one mapping of created roles to users is shown above, where user JohnW has (by default), only one role assigned: also named JohnW. (Note additional roles could be assigned, but are not here.) Effectively, nothing changed here: the permissions map that used to be in user JohnW’s permissions property is now in the “same named” Role component.

Figure 22.   Permissions map of User relocated to Role created with identical name

As shown above, you can see this in the popup Edit window for each Role (in the Role Manager view on the RoleService). The role now has the permissions map.

In summary, to make better use of roles, you should consider this a workaround effect of migration. For example, you could create more duty specific roles and/or rename or delete roles, later reassigning to users in various combinations. When adding or editing users, this can simplify how permissions are assigned.

The Role Manager lets you do all these things, except the assignment of one or more roles to users. That you do from editing (or adding new) users in the User Manager, or from User property sheets.