Hi,
I’m looking for a way to differentiate between external (mainly
customers) and internal users (emplyees) while sending notifications.
From what I figured out this cannot be done within the template itself.
Should I write custom code and plug it in with some callback or is there
any other way?
Regards,
Robert Wysocki
administrator systemów linuksowych
administrator baz danych
Grupa Unity | ul. Przedmiejska 6-10, 54-201 Wrocław
ul. Conrada 55B, 31-357 Kraków | ul. Złota 59, 00-120 Warszawa
I’m looking for a way to differentiate between external (mainly
customers) and internal users (emplyees) while sending notifications.
From what I figured out this cannot be done within the template itself.
Should I write custom code and plug it in with some callback or is there
any other way?
Often people do this by having AdminCcs be internal and Requestors/Ccs
be external. This way they naturally use two separate Templates.
If you tell us more specifically what you’re trying to accomplish,
someone might be able to suggest a solution.
-kevin
Dnia 2013-07-31, śro o godzinie 12:10 -0400, Kevin Falcone pisze:
I’m looking for a way to differentiate between external (mainly
customers) and internal users (emplyees) while sending notifications.
From what I figured out this cannot be done within the template itself.
Should I write custom code and plug it in with some callback or is there
any other way?
Often people do this by having AdminCcs be internal and Requestors/Ccs
be external. This way they naturally use two separate Templates.
This would be a nice solutions except not everybody likes to receive
tons of comments as AdminCc.
If you tell us more specifically what you’re trying to accomplish,
someone might be able to suggest a solution.
Our RT web interface is used mainly locally. We have links included in
templates, but external users usually don’t have credentials to log in
into web interface, so links just confuse them.
We’d like to split templates so that only those with access get links
and others don’t.
Regards,
Robert Wysocki
administrator systemów linuksowych
administrator baz danych
Grupa Unity | ul. Przedmiejska 6-10, 54-201 Wrocław
ul. Conrada 55B, 31-357 Kraków | ul. Złota 59, 00-120 Warszawa
Dnia 2013-07-31, śro o godzinie 12:10 -0400, Kevin Falcone pisze:
I’m looking for a way to differentiate between external (mainly
customers) and internal users (emplyees) while sending notifications.
From what I figured out this cannot be done within the template itself.
Should I write custom code and plug it in with some callback or is there
any other way?
Often people do this by having AdminCcs be internal and Requestors/Ccs
be external. This way they naturally use two separate Templates.
This would be a nice solutions except not everybody likes to receive
tons of comments as AdminCc.
You can tune what Scrips run, although if some people do and some
people don’t, it’s difficult.
If you tell us more specifically what you’re trying to accomplish,
someone might be able to suggest a solution.
Our RT web interface is used mainly locally. We have links included in
templates, but external users usually don’t have credentials to log in
into web interface, so links just confuse them.
We’d like to split templates so that only those with access get links
and others don’t.
Unfortunately, RT uses one template to generate all the mail to all
the Requestors, so you can’t solve this with templates.
One way to solve this is having some custom notification actions
(perhaps with rt-email-group-admin to notify some internal users
separately from the others).
The only real solution is likely to have some sort of
Notify Privileged Users vs Notify Unprivileged Users Scrip Actions
that subclass the Notify action and override which Requestors are
picked. It’ll be weird because half the Requestors would be notified
in a clump and then the others would be notified.
Or to convert RT to sending one email per user.
-kevin
Dnia 2013-08-01, czw o godzinie 12:21 -0400, Kevin Falcone pisze:
Our RT web interface is used mainly locally. We have links included in
templates, but external users usually don’t have credentials to log in
into web interface, so links just confuse them.
We’d like to split templates so that only those with access get links
and others don’t.
Unfortunately, RT uses one template to generate all the mail to all
the Requestors, so you can’t solve this with templates.
One way to solve this is having some custom notification actions
(perhaps with rt-email-group-admin to notify some internal users
separately from the others).
The only real solution is likely to have some sort of
Notify Privileged Users vs Notify Unprivileged Users Scrip Actions
that subclass the Notify action and override which Requestors are
picked. It’ll be weird because half the Requestors would be notified
in a clump and then the others would be notified.
Or to convert RT to sending one email per user.
Few months ago I’ve implemented something similar - a “role” for traffic
manager. It consists of a per-queue custom field, some local
modifications in Action.pm and custom ScripActions in DB.
I’ll probably gonna try to customize it so that we can have the kind of
ScripActions you’ve mentioned.
In my opinion it would be great to have a easy-to-use mechanism for
creation of custom roles like ‘Requestor’ od ‘AdminCc’.
Regards,
Robert Wysocki
administrator systemów linuksowych
administrator baz danych
Grupa Unity | ul. Przedmiejska 6-10, 54-201 Wrocław
ul. Conrada 55B, 31-357 Kraków | ul. Złota 59, 00-120 Warszawa
Few months ago I’ve implemented something similar - a “role” for traffic
manager. It consists of a per-queue custom field, some local
modifications in Action.pm and custom ScripActions in DB.
I’ll probably gonna try to customize it so that we can have the kind of
ScripActions you’ve mentioned.
You could probably do that with subclassing rather than direct
modifications, but it sounds like you need some pretty significant
changes.
In my opinion it would be great to have a easy-to-use mechanism for
creation of custom roles like ‘Requestor’ od ‘AdminCc’.
It sure would, but it’s a rather complicated piece of the system and
it’s very easy to add huge performance bottlenecks.
The development version of RT includes significant refactoring to
make it easier to add new roles.
-kevin