Hi RT Users,
I am trying to clear an address that keeps appearing in the
One-time Cc/Bcc list on the Reply form for a ticket. The user
is no longer here, but the address keeps showing up in the
Reply form for new tickets. How is that list constructed?
Regards,
Ken
Hi RT Users,
I am trying to clear an address that keeps appearing in the
One-time Cc/Bcc list on the Reply form for a ticket. The user
is no longer here, but the address keeps showing up in the
Reply form for new tickets. How is that list constructed?
Hi Ken,
What version of RT are you using?
-m
Hi RT Users,
I am trying to clear an address that keeps appearing in the
One-time Cc/Bcc list on the Reply form for a ticket. The user
is no longer here, but the address keeps showing up in the
Reply form for new tickets. How is that list constructed?Hi Ken,
What version of RT are you using?
-m
We are currently running 3.8.last and working on an upgrade to
4.2.x.
Regards,
Ken
Hi RT Users,
I am trying to clear an address that keeps appearing in the
One-time Cc/Bcc list on the Reply form for a ticket. The user
is no longer here, but the address keeps showing up in the
Reply form for new tickets. How is that list constructed?Regards,
Ken
Okay. It looks like I can add the address to the $RTAddressRegexp
and it will remove it. I was hoping that there was some type of
DB/shredder/GUI action that could be used instead of polluting
the regex.
Regards,
Ken
The “One-time Cc” list is constructed by collecting all of the addresses
related to all of the ticket’s transactions and then removing addresses
belonging to requestors.
Is someone still regularly CC-ing this departed user in new tickets?
Alternatively (although I’m not sure that this is relevant), is that RT
user set up as a queue-level CC?
By adding this user’s address to the $RTAddressRegexp regex, you’re telling
RT that it directly receives mail to that address, which could have
unintended consequences (e.g. inability to add or re-add this email address
to tickets).On 17 December 2014 at 06:39, ktm@rice.edu ktm@rice.edu wrote:
On Mon, Dec 15, 2014 at 04:08:52PM -0600, ktm@rice.edu wrote:
Hi RT Users,
I am trying to clear an address that keeps appearing in the
One-time Cc/Bcc list on the Reply form for a ticket. The user
is no longer here, but the address keeps showing up in the
Reply form for new tickets. How is that list constructed?Regards,
KenOkay. It looks like I can add the address to the $RTAddressRegexp
and it will remove it. I was hoping that there was some type of
DB/shredder/GUI action that could be used instead of polluting
the regex.Regards,
Ken
The “One-time Cc” list is constructed by collecting all of the addresses
related to all of the ticket’s transactions and then removing addresses
belonging to requestors.Is someone still regularly CC-ing this departed user in new tickets?
Alternatively (although I’m not sure that this is relevant), is that RT
user set up as a queue-level CC?By adding this user’s address to the $RTAddressRegexp regex, you’re telling
RT that it directly receives mail to that address, which could have
unintended consequences (e.g. inability to add or re-add this email address
to tickets).
Hi Alex,
I know about the pitfall of using $RTAddressRegexp but the problem
I have is that even for new test tickets created by Email that I send
which definitely does not have the address in question as a Cc, the
address is added as a one-time Cc/Bcc option. 
I tried to find a
commandline script to pull the addresses to see if I could figure out
where the address is originating, but I did not succeed. It would be
fine if the address was only added if it was Cc-ed earlier.
Regards,
Ken> On 17 December 2014 at 06:39, ktm@rice.edu ktm@rice.edu wrote:
On Mon, Dec 15, 2014 at 04:08:52PM -0600, ktm@rice.edu wrote:
Hi RT Users,
I am trying to clear an address that keeps appearing in the
One-time Cc/Bcc list on the Reply form for a ticket. The user
is no longer here, but the address keeps showing up in the
Reply form for new tickets. How is that list constructed?Regards,
KenOkay. It looks like I can add the address to the $RTAddressRegexp
and it will remove it. I was hoping that there was some type of
DB/shredder/GUI action that could be used instead of polluting
the regex.Regards,
Ken
I have is that even for new test tickets created by Email that I send
which definitely does not have the address in question as a Cc, the
address is added as a one-time Cc/Bcc option.
commandline script to pull the addresses to see if I could figure out
where the address is originating, but I did not succeed. It would be
fine if the address was only added if it was Cc-ed earlier.
[I’m assuming you mean the checkboxes that appear near one-time-cc/one-time-bcc]
That list comes from Ticket->TransactionAddresses which calls
Attachment->Addresses and it looks on From/To/Cc/a few other things on
each correspond/comment in the ticket, so somewhere in there, that
email must appear. Maybe the code (which is quite simplistic) will
shed some light.
-kevin
I have is that even for new test tickets created by Email that I send
which definitely does not have the address in question as a Cc, the
address is added as a one-time Cc/Bcc option.
commandline script to pull the addresses to see if I could figure out
where the address is originating, but I did not succeed. It would be
fine if the address was only added if it was Cc-ed earlier.[I’m assuming you mean the checkboxes that appear near one-time-cc/one-time-bcc]
That list comes from Ticket->TransactionAddresses which calls
Attachment->Addresses and it looks on From/To/Cc/a few other things on
each correspond/comment in the ticket, so somewhere in there, that
email must appear. Maybe the code (which is quite simplistic) will
shed some light.-kevin
Hi Kevin,
Thank you for the information. I checked out the code and it is quite
basic, as you mentioned. I know that I did not have the Email address
in question in my test Emails so I do not know where it would have
come from. Is there any type of caching within the RT backends or
maybe the browsers that could cause that behavior? Thank you again
for the update.
Regards,
Ken