No reply to ticket status changed for non-root user?

Hello List!

I’ve installed RT 3.6.1 without problems on Debian stable (Sarge)
(thanks to the wonderful guide on
Request Tracker Wiki”).

Then i created a queue called “support”, a user “as” and a group
“it-support” (where “as” is a member).
The predefined group “Everyone” has following rights:

  • CommentOnTicket
  • CreateTicket
  • ReplyToTicket
  • SeeQueue
    The group “it-support” has following rights for the queue “it-support”:
  • ShowTicket
  • ShowTicketComments
  • Watch
  • WatchAsAdminCc
  • OwnTicket
  • ModifyTicket
    (as described on
    Request Tracker Wiki”).

However there is one problem:
If a new email is send (by a user called “as”@) to rt (queue:
“it-support”), the user “as” can see and modify that ticket in the nice
web interface. But if “as” set the ticket status on “resolved”, no mail
to the original ticket requester (aka client) is send, only the ticket
status has changed to “resolved”.
If i am logged in as the “root” user and try the same procedure (modify
a new ticket and change the status to “resolved”), all works fine: a new
mail is generated and send to the requester of that ticket. So i see the
behavior i expected for the non-root user “as” in the first time.

Any idea how to tell rt that every time a non-root user - for example
“as” - has set a ticket to “resolved” (or just tries to reply to a
ticket), a new mail to the requester of the ticket should be dispatched?

Many thanks in advance for any help!

With kind regards,
Andreas Semt


I found following in the mailing list archive:
(“Carbon60: Cloud Consulting - Services and Solutions”)
RT will not send to the requestor by default if the requestor is also a
ticket admin.
This may be what you’re running into.


Is that my problem, too (can’t try it in the moment)? If, so: sorry
for asking!
But: Why is the mail send when logged in as “root” user?? Any change to
force rt to send a reply message, even if the requester is also a
“ticket admin”?

Hello again,

Sorry, one error in my description of the problem:

The group “it-support” has following rights for the queue “it-support”:

The queue is called “support”, not “it-support” (that’s indeed the group

With kind regards,
Andreas Semt