I have a newbie question, as I’m trying to understand mod-perl/mason/rt so
I can customize it more.
The question: For things I want to edit, should I always make a copy from
the /rtpath/WebRT/path to /rtpath/local/WebRT/path and then edit the
local/WebRT file?
Example: copy /usr/local/rt2/WebRT/html/Elements/MyTickets to
/usr/local/rt2/local/WebRT/html/Elements/MyTickets
I guess this leaves the original source code as a backup?
Thanks,
Jeff
Jeff Hoover wrote:
The question: For things I want to edit, should I always make a copy from
the /rtpath/WebRT/path to /rtpath/local/WebRT/path and then edit the
local/WebRT file?
Yes.
I guess this leaves the original source code as a backup?
As well as preventing “make upgrade” from clobbering your local changes.
Phil Homewood, Systems Janitor, www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances
I’ve been looking at RT for a week. I just got this job and am taking
over for someone who suddenly quit. I know PERL and am getting to know
LINUX…I come from a UNIX background so that helps.
Here’s my situation:
Our company has a group of customer service reps and my boss would
rather have them share a login username and password as a group and then
have a mandatory custom field for their real name and their email
address. That way they (as a group) can see all the tickets for the
group. He wants RT to use the email address entered as the one used for
any correspondence, not the address for the username. Also, we would
like to do field validation on the email to make sure it is a valid
email address for our mail server.
Is this feasible? I need someone to point me in the right direction. I
have “RT Essentials” ordered and on the way, but I’m not so sure that I
will learn this from it…right?
Thanks in advance,
Brian
This communication, together with any attachments hereto or links contained herein, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is STRICTLY PROHIBITED. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments hereto or links herein, from your system.
Hi Brian,
Here’s my situation:
Our company has a group of customer service reps and my boss would
rather have them share a login username and password as a group and
then have a mandatory custom field for their real name and their
email address. That way they (as a group) can see all the tickets
for the group.
What you are describing is probably better implemented as a queue (or
set of queues) with an email address. All CSRs should be in a group
that has appropriate permissions on the queue so they can see/update/
steal eachother’s tickets as needed.
This preserves accountability (actions are attributed to individual
users) which your proposed scheme above would destroy.
He wants RT to use the email address entered as the one used for any
correspondence, not the address for the username.
I’m not sure I follow. Configured as I describe above messages sent
from RT will come from the queue email address, and reply-to will
point at the queue email address. (The typical format for the “from
name” is “John Doe (via RT)”, but you can change this easily).
You COULD hack around this & override the From/Reply-To addresses, but
if you specify an address that rt-mailgate isn’t watching then
correspondence will bypass RT, which defeats the purpose of a
ticketing system…
Also, we would like to do field validation on the email to make sure
it is a valid email address for our mail server.
This is a moot point given the above – just make sure your queue
emails are (a) valid and (b) watched by rt-mailgate and everything
should take care of itself.
-MG
Hi Brian,
He wants RT to use the email address entered as the one used for any
correspondence, not the address for the username.I’m not sure I follow. Configured as I describe above messages sent from RT
will come from the queue email address, and reply-to will point at the queue
email address. (The typical format for the “from name” is “John Doe (via
RT)”, but you can change this easily).You COULD hack around this & override the From/Reply-To addresses, but if
you specify an address that rt-mailgate isn’t watching then correspondence
will bypass RT, which defeats the purpose of a ticketing system…
We do something similar at work. We did edit the "from name" to
be something like “BoogerEater Support,” while the From/Reply-To email
address is, say, support@nomnom.com; each support member then signs
his/hers/its replies and that’s that. Everyone on the support group
sees the replies in their inboxes or through RT’s webpage.