"MKS Domain" Users and Groups vs "Workflows and Documents" Users and Groups. Differences and usages?

[bbean]

During testing I discovered the "MKS Domain" Users and Groups are separate from the "Workflows and Documents" Users and Groups.

The getUserBean(LoginID ) method requires the "MKS Domain" User LoginID to work, and using the getEmailAddress() method on the user bean it returns will pass back the email address listed under the "MKS Domain" user email field(I think).

However, it appears any field that references a "User" for its value, is a reference to the "Workflows and documents"  Users. When any field is pulled using the db.getField Value("") method and returns a user, it returns the "Workflows and documents"  "Name" which is not always the same as the "MKS Domain" user loginID. Since these fields are not always the same, you can not reliably use the fields to pull back an email address. And I can find no access or modification methods to use in the triggers for the "Workflows and documents" user and group sections at all.

I would like to know what methods are used to directly access and modify the "MKS Domain" and the "Workflows and Documents" User and Group sections respectively, from the trigger.

[awalsh · Accepted solution]

When working with "Workflows and Documents" (W&D) trigger beans, the imServerBean.getUserBean(java.lang.String user)  and imServerBean.getGroupBean(java.lang.String group) method will take return beans for the W&D users and groups.  The string to give is the user or group name.

To retrieve beans for the MKS Domain, or whichever authentication realm you are using, you need to use the siEnvironmentBean.getRealmBean().getRealmUserBean(java.lang.String loginID) method.

The W&D users and groups are imported from the authentication realm you are using. This could be the MKS Domain, or it could be LDAP.  In either case, the information that you are getting from the imUserBean and imGroupBean will be what shows for the Users and Groups in the W&D administration. That is, the data you will see when running "im viewuser" and "im viewgroup".

The Full Name and Email Address are taken from the authentication realm if defined. If they are not defined in the authentication realm, then they may be defined in the W&D admin. If there is a difference between what is in the realm and what is in W&D, then the next time the user and group cache is refreshed, the realm data is copied over (and overwrites) the W&D data. 

For MKS Domain, you can test this by setting a having a user with no Full Name in the MKS Domain.  Try setting the Full Name by editing the user under the W&D node.  Then edit the same user to have a different name in the MKS Domain. Right-click on Workflows and Documents node, and select Refresh User and Group Cache. You should see the W&D user update to have the MKS Domain name.  The Full Name and Email Address cannot be modified through the W&D trigger beans.

The group memberships are also maintained in the authentication realm and cannot be changed through the W&D administration or trigger beans.

When you are retrieving the values for a user field using the imDeltaBean.getfieldValue method, if the user field is single-value, you should get the loginID, which will match what you see in the W&D user list. If the user field is multi-value, you will get an array with the loginIDs.

If you are using MKS Domain as the authentication realm, then you can make changes to the users and groups using the integrity editmksdomainuser and integrity editmksdomaingroup commands.

I've done all my testing with Integrity 11.1. If you are seeing different results in another release, please let me know which release, and which beans/methods are not returning the expected data. I can rerun my tests and also check to see if there's any changes between the releases that would affect what you are seeing.

[ssaul]

I am not bbean, but one additional comment:

I have checked this in our 10.5 release (via Admin GUI, not via triggers):

The changes made in the MKS Domain (full name, email) are updating the W&D fields after refreshing user and group cache only for ACTIVE users.

[cdoyle]

To provide some additional background to Ann's answer, the MKS Domain is a lightweight Directory service that is built into the PTC Integrity Server.  It was originally implemented to address the needs of customers who did not have a corporate Directory service such as LDAP or MS Active Directory from which to enumerate users and groups and where users could be authenticated.  As such, the MKS Domain is separate from the W&D Users and Groups, which track the users and groups registered within the Workflows and Documents component of the PTC Integrity functionality.  As Ann describes, the W&D Users and Groups are essentially proxying the data from the underlying Directory service(s).

While most PTC customers use a corporate Directory service today, the MKS Domain is still very useful for managing temporary users (e.g. contractors or auditors) and for managing Integrity-specific groups.  This allows the PTC Integrity administrator to quickly update the MKS Domain if a group's membership changes, or a temporary worker needs to be added or deactivated, whereas getting such changes made in the corporate Directory service can take much longer to complete.

[bbean]

This is exactly the information I was looking for. Thank you so much for responding.

[bbean]

Thank you for responding. The code snips you shared have been very helpful!