Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

how do you surpress email from a large work item migration?

Well, we should have saw this one coming, but we just imported a 
thousand records into RTC and immediately started getting pinged 
about the flood of email users were getting.  

We did want to let them know that the migration into RTC 
was complete, but not one record at a time :) 

Question 1:  is there a smarter way than just turning off email 
for the whole repository to avoid email to every ticket owner?

Question 2: the poor guy that did the import is now subscribed to 
every work item. 

Might someone have a script that uses the API to remove a 
subscriber from a named set of tickets? 

A nice toggle for email preferences would be to surpress attaching 
me as a suscriber to tickets I create.  

0 votes

Comments

In another posting ,  it was noted that work item  140179 is an enhancement request for suppressing email notifications.  however , i cannot find that work item .  Can someone tell me how to find the enhancement request - 140179?



3 answers

Permanent link
For your second question, I don't have a script, but if you're using RTC 4.0, you can do this from the eclipse client. 
1. Create a query that will return all of the work items this user wants to unsubscribe to
2. Run the query in the eclipse client
3. Select all the work items it returns, right click and select Subscriptions->Unsubscribe me

0 votes

Comments

Thanks Mark - this  is a good tip for 4.0 users.  

Anyone have help for those of us still on 3.x?


Permanent link
Has anyone tried to switch e-mail notification off on the server (advanced properties). If it is off, the server should not send e-mails, right? And that should preserve the subscriptions too.
Unfortunately none of my test servers is set up with e-mail notification, so I can't test. I would be interested in the outcome however.

0 votes

Comments

Ralph - I would expect that turning off email during the migration would prevent the initial flood of email, but that is a pretty blunt instrument if there are other teams currently in the production system.  For our case, the migration took quite a bit of manual intervention so was done over a three day period. 

Hi Virginia, that is a valid concern. In that case some automation would be useful. See some hints and techniques on http://rsjazz.wordpress.com.

See http://rsjazz.wordpress.com/2012/11/19/using-an-expression-to-synchronize-attributes-for-work-items-of-a-specific-type/ as an idea how to iterate the work items with an expression and use a WorkItemOperation to manipulate it. And http://rsjazz.wordpress.com/2012/08/02/subscribing-to-a-work-item-using-the-java-api/ about subscriptions (it subscribes, I assume it is relatively easy to find out how to unsubscribe).

This post discusses a possible issue with disabling email for a short period of time.  I wonder if anyone else has seen the same behavior.

https://jazz.net/forum/questions/92117/disabling-the-email-notification-for-some-period-of-time


Permanent link
I think we need a routine that can

1. get the email status for a user
2. set the send me an email flag for that user (to off) for the migration period

later use the data from 1, to restore the send me an email flag, for the user.

| based on quick review of the code, this looks like it will require use of internal classes

no internal classes required.. get the users details record and the email config from the extended attributes
the email config is stored in this key "com.ibm.team.workitem.mail.Configuration", and it is an xml document.
if not previously set, the server code uses a default string.

given the contributor record, and the  item manager from the repository connection you can get the email config like this

        IContributorDetailsHandle detailsHandle= contributor.getDetails();
        if (detailsHandle != null)
        {
            IContributorDetails details=
            (IContributorDetails) iim.fetchPartialItem(detailsHandle, IItemManager.REFRESH,
                Collections.singleton(
                IExtensibleItem.ALL_STATE_EXTENSIONS_PROPERTY),null);
            // get the writeable copy of the details
            details=(IContributorDetails) details.getWorkingCopy();                  
            // get the email config value, if any
            String configVal= details.getLargeStringExtension(CONFIG_KEY);
         }



0 votes

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,029
× 119

Question asked: Nov 20 '12, 10:52 a.m.

Question was seen: 5,922 times

Last updated: Feb 17 '13, 9:27 a.m.

Confirmation Cancel Confirm