Hi,
I just installed RT on a CentOS 4 server (Red Hat Enterprise Linux 4)
via RPM, all went well, but I have a few questions. I’m still in test
phase. I’ve read the FAQ and wen through the book “RT essentials”.
Here is my context: I have a few clients and I'd like to use RT to
manage their requests
Question 1: My ISP blocks ports 25 and 80 incoming, so I set up a
fetchmail cronjob that gets messages for rt@mydomain.com. I did set up
the alias so that mailgate gets it. Is that OK? Up to now, it seems to
be working perfectly. I don’t really mind having to use an alternate
port for the web interface, and I’m thinking about not giving access to
the web interface to my clients anyway. Any comments?
Question 2: Virtual host: Since I installed RT, the rpm seems to have
set up a virtual host, and since then I cannot access the stock web root
(/var/www/html/). I guess I have to set up another virtual host for the
stock web root and set it as default?
Question 3: I’d like to receive by e-mail a notification when a new
ticket is created, so that I don’t have to always have the web interface
open to know there is a new request. How do I do that? With scrips?
That is about it for now.
TIA,
Ugo
Ugo Bellavance wrote:
Hi,
That is about it for now.
Not really… I also wanted to know if it was a good idea to have one
queue for every client (I don’t mind creating the aliases), so that they
each have a specific e-mail address (client-support@domain.com) instead
of a generic one (support@domain.com).
That is about it for now.
Not really… I also wanted to know if it was a good idea to have one
queue for every client (I don’t mind creating the aliases), so that they
each have a specific e-mail address (client-support@domain.com) instead
of a generic one (support@domain.com).
I usually base the queues on the set of users that will be
responding to them. You can set up any number of email aliases
for the original request message pointing into the same
queue. The only part where you need different queues for
a visible difference is if you want the auto-response to be
different or if you need to maintain a different reply
address on the responses for vanity reasons. Functionally
a single reply address is fine for all queues because the
ticket number in the subject line is used to map replies back
to the original ticket regardless of its current queue.
Les Mikesell
les@futuresource.com
Ugo Bellavance ugob@camo-route.com writes:
Question 3: I’d like to receive by e-mail a notification when a new
ticket is created, so that I don’t have to always have the web
interface open to know there is a new request. How do I do that?
With scrips?
Either by adding a global script to notify you on ticket creation, or
by adding yourself as AdminCC for each queue (I think the “Notify
AdminCCs on creation” scrip is part of the default installation).
Espen Wiborg espenhw@ovitas.no
99 little bugs in the code, 99 bugs in the code,
fix one bug, compile it again, 101 little bugs in the code.
Ugo Bellavance ugob@camo-route.com writes:
Not really… I also wanted to know if it was a good idea to have
one queue for every client (I don’t mind creating the aliases), so
that they each have a specific e-mail address
(client-support@domain.com) instead of a generic one
(support@domain.com).
We do both (sort of). Each customer has one queue (or in some cases
several queues), but we have a generic support@ address, using
procmail to dispatch to the correct queue based on the sender’s
domain.
Espen Wiborg espenhw@ovitas.no
99 little bugs in the code, 99 bugs in the code,
fix one bug, compile it again, 101 little bugs in the code.
Not really… I also wanted to know if it was a good idea to have one
queue for every client (I don’t mind creating the aliases), so that
they
each have a specific e-mail address (client-support@domain.com)
instead
of a generic one (support@domain.com).
In our setup… “big” customers get their own queue’s… and everyone
else is lumped into one queue.
When we break out customers to have their own queue, they get a Helpdesk
and a Projects.
Breaking them out is helpful in terms of granting permissions to clients
to see their tix etc.
duncan
Question 3: I’d like to receive by e-mail a notification when a new
ticket is created, so that I don’t have to always have the web interface
open to know there is a new request. How do I do that? With scrips?
Add the users or groups that should receive mail as admincc watchers
for the queue and the default scrips will do that.
Les Mikesell
les@futuresource.com
Not really… I also wanted to know if it was a good idea to have one
queue for every client (I don’t mind creating the aliases), so that
they each have a specific e-mail address (client-support@domain.com)
instead of a generic one (support@domain.com).
In our setup… “big” customers get their own queue’s… and everyone
else is lumped into one queue.
Ok, I’d like one customer specifically to have its own queue to have a
different subject in the auto-replies, because I’m an outsourcer for one
of my client. Basically, I work for client A. Client B is Client A’s
Client. Client A pays me to work for Client B. So I’d like to have
"Client A in all the auto-replies, when Client A or Client B creates a
new request in RT.
When we break out customers to have their own queue, they get
a Helpdesk
and a Projects.
Breaking them out is helpful in terms of granting permissions
to clients
to see their tix etc.
What do you mean by breaking?
Breaking them out is helpful in terms of granting permissions
to clients
to see their tix etc.
What do you mean by breaking?
Sorry…you can replace ‘breaking out’ with ‘Separating’ or ‘divding’
duncan
Espen Wiborg wrote:
Ugo Bellavance ugob@camo-route.com writes:
Question 3: I’d like to receive by e-mail a notification when a new
ticket is created, so that I don’t have to always have the web
interface open to know there is a new request. How do I do that?
With scrips?
Either by adding a global script to notify you on ticket creation, or
by adding yourself as AdminCC for each queue (I think the “Notify
AdminCCs on creation” scrip is part of the default installation).
I have only one queue for now, and I added my user to the AdminCC for
this queue. I created a ticket via e-mail and my user didn’t get an e-mail.
I went to the queue right settings and figured out my user, although
superuser in the system, had no rights in this queue…
Does it have anything to do?
If I’m the only one managing RT, what kind of rights should I give my user?
Thanks,
Duncan Shannon wrote:
Not really… I also wanted to know if it was a good idea to have one
queue for every client (I don’t mind creating the aliases), so that
they
each have a specific e-mail address (client-support@domain.com)
instead
of a generic one (support@domain.com).
In our setup… “big” customers get their own queue’s… and everyone
else is lumped into one queue.
Ok, I’d like one customer specifically to have its own queue to have a
different subject in the auto-replies, because I’m an outsourcer for one
of my client. Basically, I work for client A. Client B is Client A’s
Client. Client A pays me to work for Client B. So I’d like to have
“Client A in all the auto-replies, when Client A or Client B creates a
new request in RT.”
Is it possible?
Ugo Bellavance ugob@camo-route.com writes:
I have only one queue for now, and I added my user to the AdminCC for
this queue. I created a ticket via e-mail and my user didn’t get an
e-mail.
This is RT’s default behavior: it will not notify the actor of
activities on the ticket (i.e., if you create the ticket yourself, you
will not get AdminCC notifications). This behavior can be altered by
changing the NotifyActor setting (in RT_SiteConfig.pm).
Espen Wiborg espenhw@ovitas.no
Tigers have striped skin, not just striped fur.
Espen Wiborg wrote:
Ugo Bellavance ugob@camo-route.com writes:
I have only one queue for now, and I added my user to the AdminCC for
this queue. I created a ticket via e-mail and my user didn’t get an
e-mail.
This is RT’s default behavior: it will not notify the actor of
activities on the ticket (i.e., if you create the ticket yourself, you
will not get AdminCC notifications). This behavior can be altered by
changing the NotifyActor setting (in RT_SiteConfig.pm).
It was an e-mail routing problem… my fault. Running on a DHCP natted
addresss isn’t ideal. I solved the problem by setting my user to a
local address (@localhost). Thanks!