Dan Bristol

Yup, 

Pretty disappointing!  

They also just closed a ticket on me regarding this issue without even letting me know.  I inquired about the status, and then didn't even hear back, so I went to look at the ticket, and it was closed.  I had to open a new one again, and still haven't heard anything on that one.  

They were supposed to refer it to services to see about coding a small piece of the API / url solution to remove a user cc.  

Maybe everyone should just open tickets, so someone else in the organization notices?  

Please, 

Can I request that the ability to remove CCs also be included when this is implemented in 6 years from now?  

That way we will not have to start this decade long process over again.  

Yup, 

I opened up a ticket and had my request sent over to the services group.  They don't even seem to want to touch this one, even though all I need to finish making this work through the API and url targets is a half line of code to remove CCs for a specific user.  

I have adding CCs via triggers and automations working well.  

That's something I guess, but it is not even close to what people have been begging for for 5 years.  

Presumably users will be able to subscribe and get updates, and perhaps you can make this work for a group of people that needs to be updated (lab operators about instrument status in our case), by turning an e-mail group into a user.  

Questions though: 

Will subscribed users be able to pick and choose what information they get; like Created tickets from the organization vs. Solved ticket updates?  

Will Subscribed Users be able to reply and add content to tickets whether it was sent out to a individual or a group?  

Lastly, and most importantly, because this problem is unacceptable, If subscribers reply to ticket updates, will this fix get around the problem of duplicate tickets created when people reply via the e-mail target function, which will then re-invoke any triggers for new / created tickets?  

Yeah,

Maybe another update on the timeline would be nice!  This has taken way too long. 

This is an especially outrageous scenario considering that replies to the target notifications create a new ticket, and then again invoke any notification triggers you have in place.  If you can’t deliver the whole fix, can you at least address this issue?  It does not look good.  Maybe have the target notifications sent out from another address?  You could also have a bounce back e-mail that the ticket was not updated, so the customer knows, and direct them to sign on and add to the ticket.  

 

Thanks, 

Yes, 

We very much need this, as the workaround is not ideal at all.  

One of our organizations needs to notify an e-mail group, so all the operators in the lab are aware of instrument issues.  If any of the operators reply to the e-mail from the notify target trigger, then it creates a new ticket and invokes the trigger again, sending another e-mail to the same group.  

Also, it would be great if they could reply to the e-mail and have it captured in the ticket.  That way we can collect additional operator observations on a given instrument issue.  

 

Thanks!