How do I change, including setting to blank, email addresses for users?

[smccoy]

Hi,

We have a couple of cases where we need to change an email address for users in our staging/production environment. Currently, the email field is only editable in items in the MKS Domain. User objects under Workflows and Documents do not allow the email addresses to be edited.

We have both 'MKS Domai'n and LDAP users where we need to change, or clear-out, the current email addresses.

Please advise.

-Sean

[JoeBartlett]

Hi Sean,

When using LDAP as your backing authentication realm, Integrity pulls its user data from the directory service. If you want to blank-out the user email addresses you will need to had an LDAP administrator blank-out the mail address of the user object in AD.

Note that this change will not be seen until the next time Integrity refreshes its cache by pulling directory data for that user account. Refreshing the user/group cache does not guarantee this update, however, there is server-wide property which controls the frequency of updates:

mksis.ldapCacheRefreshInterval (note the default time of 12 hours)

Also, an Integrity Server restart will force the update though this is not always an option throughout the day.

[JoeBartlett]

Something that just occurred to me - why are you wanting to blank-out the user email addresses? Is it because users receive bogus emails from Dev or Test servers in the staging chain when people are testing new solution changes? If so, you can modify Dev and Test to stop sending SMTP emails altogether with the mksis.mailserver property on the same screen I showed in my post above.

[smccoy]

Hi Joe,

There are 2 answers to your question.

1) For LDAP users... We had some folks play around with item assignments.We have triggers that fire when item assignments change. Add those two together and a manager wasn't happy to get silly emails from our Integrity solution. The request is to simply blank out the email address for that user in Integrity.

2) For MKSDomain users... We have a handful of "virtual people" that do not have LDAP users. A couple folks requested to have their email address(s) setup for these "virtual people". Once they saw the amount of email, and types of messages, those users have changed their mind and want their email address removed. The request is to blank-out the email address for this MKSDomain users.

-Sean

[JoeBartlett]

Ah, I see. The way to blank-out your LDAP user is what I outlined above and the way to blank-out email for mksdomain users is to make the edits manually. Each server has its own separate mksdomain values (you can think of it sort of like different domains) so unfortunately you can't stage mksdomain data like you can with Types, States, Queries, Workflow User objects, etc.

If you are interested, Article 87193 talks about the enhancement request RFC (136414) we have to make mksdomain objects part of the Workflow and Document admin staging functionality.

[JoeBartlett]

Re-reading your explanation of the LDAP user needing to stop getting emails, I see that stopping emails completely as I suggested will not quite work for you (since you still want to have users test item assignments). The easiest thing to do immediately in my opinion is to change the notification trigger scripts to have an "exclusion user list" kind of parameter where you can specify a list of email addresses to ignore.

If the problem is with the Notifications defined on the user or group objects, an administrator has the power to edit those and I recommend removing them completely for the users on Dev and Test unless someone explicitly wants to set them for testing.

[smccoy]

Hi Joe,

We'll deal with the LDAP variation of this problem on own own by changing some scripts.

For the MKSDomain users there are 4 different representations of each "virtual user" - 2 on the admin server and 2 on the production server; one in the MKS Domain|Users and one under Workflows and Documents|Users.

For the admin server:

MKS Douman|Users|VirtualUser1 - the email address is editable and has been cleared out.

Workflows and Docouments|Users - the email address is not editable with no explanation as to why

Making changes to items on the admin server generates emails that get sent to the email address for the user under Workflows and Documents. We've waited 18+hours for the change from the MKS Domain to be propagated to the Workflows and Documents, but it appears that there isn't a synchronization process for these users.

For the production server:

MKS Douman|Users|VirtualUser1 - the email address is editable and has been cleared out.

Workflows and Docouments|Users - the email address is not editable because the sever is locked

Making changes to items on the production server generates emails that get sent to the email address for the user under Workflows and Documents. Again, we've waited 18+hours for the change from the MKS Domain to be propagated to the Workflows and Documents, but it appears that there isn't a synchronization process for these users.

So the question remains... How do we clear-out the email addresses for the users under "Workflows and Documents|Users" that are 'copies' of the MKS Domain users?

-Sean

[JoeBartlett]

Hi Sean,

The user objects you see under Workflows and Documents do not allow the email address to be edited because they are pulling that information from the backing realm, whether that be mksdomain or LDAP. A way I found to force an update of the user data is to edit the W&D user object (without any changes, just clicking OK to the window).

This method has 2 problems I can see:

1. If there are more than a few users, this will be extremely tedious.
2. If you want to clear-out users on a locked staging server (2nd or 3rd in the chain) then you can't just edit the object. In this case you would probably be stuck with a server restart as the only option to force the refresh.

Message was edited by: Joseph Bartlett There also appears to be an enhancement request for the W&D user object cache data to be updated when a change occurs in the mksdomain realm. Article 88924 has details: https://www.ptc.com/appserver/cs/view/solution.jsp?n=CS88924