We have a couple of SquelchMailTo ticket attributes which suppress
outgoing email for some tickets. I’m not sure how these attributes
were added (there does not seem to be any UI for this task). Is it
safe to delete them?
At Tuesday 7/5/2005 10:26 AM, Florian Weimer wrote:
We have a couple of SquelchMailTo ticket attributes which suppress
outgoing email for some tickets. I’m not sure how these attributes
were added (there does not seem to be any UI for this task). Is it
safe to delete them?
The controls for this are on the ticket Reply screen - the section labelled
something like ‘this mail will not be sent to’. Uncheck the names listed.
Steve
- Stephen Turner:
At Tuesday 7/5/2005 10:26 AM, Florian Weimer wrote:
We have a couple of SquelchMailTo ticket attributes which suppress
outgoing email for some tickets. I’m not sure how these attributes
were added (there does not seem to be any UI for this task). Is it
safe to delete them?The controls for this are on the ticket Reply screen - the section
labelled something like ‘this mail will not be sent to’. Uncheck the
names listed.
Yes, I’ve figured this out. However, I don’t really understand how
these values have been added to the database permanently; this has
only happened for very few tickets. This inconsistency confuses my
users.
We have a couple of SquelchMailTo ticket attributes which suppress
outgoing email for some tickets. I’m not sure how these attributes
were added (there does not seem to be any UI for this task). Is it
safe to delete them?
On the ticket reply page, users can optionally tell RT not to ever send
mail to a given ticket watcher. Presumably one of your users did this
intentionally 
Jesse
We have a couple of SquelchMailTo ticket attributes which suppress
outgoing email for some tickets. I’m not sure how these attributes
were added (there does not seem to be any UI for this task). Is it
safe to delete them?On the ticket reply page, users can optionally tell RT not to ever send
mail to a given ticket watcher. Presumably one of your users did this
intentionally
(Sorry, that’s what I get for not reading mail in mutt’s “threaded” view
- Jesse Vincent:
We have a couple of SquelchMailTo ticket attributes which suppress
outgoing email for some tickets. I’m not sure how these attributes
were added (there does not seem to be any UI for this task). Is it
safe to delete them?On the ticket reply page, users can optionally tell RT not to ever send
mail to a given ticket watcher. Presumably one of your users did this
intentionally(Sorry, that’s what I get for not reading mail in mutt’s “threaded” view
Huh?
Now I’m really confused what’s going on. I’m running a sightly
customized version of RT 3.4.2 (html/Ticket/Elements/PreviewScrips
hasn’t been edited), and I don’t see such a user interface. A quick
try shows that in general, suppressing mail isn’t persistent, either.
What am I missing?
- Jesse Vincent:
We have a couple of SquelchMailTo ticket attributes which suppress
outgoing email for some tickets. I’m not sure how these attributes
were added (there does not seem to be any UI for this task). Is it
safe to delete them?On the ticket reply page, users can optionally tell RT not to ever send
mail to a given ticket watcher. Presumably one of your users did this
intentionally(Sorry, that’s what I get for not reading mail in mutt’s “threaded” view
Huh?
I meant that it appeared that other folks had actually answered the
question.
Now I’m really confused what’s going on. I’m running a sightly
customized version of RT 3.4.2 (html/Ticket/Elements/PreviewScrips
hasn’t been edited), and I don’t see such a user interface.
There’s a right for it, though I don’t remember it off the top of my
head.
A quick try shows that in general, suppressing mail isn’t persistent, either.
It should be persistent, per ticket. So you can say “Don’t email joe
about ticket 1234.”
- Jesse Vincent:
Now I’m really confused what’s going on. I’m running a sightly
customized version of RT 3.4.2 (html/Ticket/Elements/PreviewScrips
hasn’t been edited), and I don’t see such a user interface.There’s a right for it, though I don’t remember it off the top of my
head.
I was logged in as a superuser while testing the persistency on
another ticket.
A quick try shows that in general, suppressing mail isn’t persistent, either.
It should be persistent, per ticket. So you can say “Don’t email joe
about ticket 1234.”
Hmm, reading the source code, it should work the way you describe it.
I’ll run another test. Strange.
- Florian Weimer:
It should be persistent, per ticket. So you can say “Don’t email joe
about ticket 1234.”Hmm, reading the source code, it should work the way you describe it.
I’ll run another test. Strange.
Okay, found it. There are two submission buttons, “Update Ticket” and
“Save changes” (with inconsistent capitalization, BTW). Obviously,
someone ticked a few email addresses and hit “Save changes”.
Maybe it’s just me, but I find this user interface confusing,
especially because RT doesn’t usually offer two separate forms which
can be used to make different changes/updates. Maybe some UI update
could fix this.
Okay, found it. There are two submission buttons, “Update Ticket” and
“Save changes” (with inconsistent capitalization, BTW). Obviously,
someone ticked a few email addresses and hit “Save changes”.Maybe it’s just me, but I find this user interface confusing,
especially because RT doesn’t usually offer two separate forms which
can be used to make different changes/updates. Maybe some UI update
could fix this.
Yeah, I don’t like that either. It’s confusing and not quite clear at
first.
I’ve personally always stuck with “Update Ticket” because I’ve always
assumed that “Save changes” meant a permanent change would be made (e.g.
don’t ever send replies to a particular watcher). Usually, I don’t want
to do this.
However, once you know how the buttons work, it’s not so bad, even if
figuring it out in the first place might be a little difficult. 
Regards,
Ranbir
Kanwar Ranbir Sandhu
Systems Aligned Inc.
www.systemsaligned.com
Florian Weimer wrote:
Okay, found it. There are two submission buttons, “Update Ticket” and
“Save changes” (with inconsistent capitalization, BTW). Obviously,
someone ticked a few email addresses and hit “Save changes”.
Unfortunately, due to localization, making the capitalization consistent
isn’t quite as simple as it would seem.
Maybe it’s just me, but I find this user interface confusing,
especially because RT doesn’t usually offer two separate forms which
can be used to make different changes/updates. Maybe some UI update
could fix this.
Do you have any specific suggestions for what you’d like to see change
in the UI? I’m all for making things more intuitive.
Cheers,
Tom