Hi Tim,
I'm not volunteering to build a custom module, but I don't think you need
one. I'm pretty sure you can do what you want simply with a User Defined
condition that traps the custom field change and NotifyOtherRecipients as
the action. You make a custom template that has your basic boilerplate in
it and do a little bit of coding to get the contents of the custom field
and then the members of that group and then the e-mail addresses of the
group's members.
Your scrip condition would be something like:
return $self->TransactionObj->Type eq 'CustomField' &&
$self->TransactionObj->Field eq 'Building';
In your template you get the value of the field with:
my $bldg = $Ticket->FirstCustomFieldValue('Building');
I haven't written anything to enumerate members of a group, but it's
probably pretty straightforward. After you get the group members, you
cycle through them using something like:
my $addresslist = "";
while ( my $user = $Group->Next ) {
$addresslist .= ", " if $addresslist;
$addresslist .= $user->EmailAddress;
}
Then you do the e-mail:
$OUT = "From: $from_address
To: $addresslist
Subject: $subject
Boilerpalte text goes here.
";
Regards,
Gene
At 02:09 PM 8/22/2007, Tim Wilson wrote:
Everyone,
This looks like a useful and flexible approach. I already have an "On
Create" scrip that inspects the requestor and sets the "Building" custom
field from the user's LDAP record. Now it seems to me that the best
approach going forward is to create a scrip that triggers whenever that
custom field gets changed. That should fire off after the original On
Create scrip runs and anytime the field is changed subsequently, right? (I
can imagine a situation where the Building CF would be set incorrectly
requiring some manual intervention. Tying the scrip to that CF value
changing would be useful in that situation.)
For the Condition, I'll use the custom one referenced in the wiki here:
http://wiki.bestpractical.com/view/OnCustomFieldValueChange
The template seems straightforward too.
That leaves me with a question about the scrip action. To make it as
generalizable as possible, wouldn't I want to create an Action as a perl
module (let's call it "Notify Building Tech Team") that grabs the newly
changed "Building" custom field value and then pulls the list of techs
from the corresponding group? This shouldn't require a custom action for
each different building right?
Next question: Who can build this for me? It's well outside my perl
comfort zone, and I'll pay the going rate. Send me a private email if
you're interested.
Thanks.
-Tim
>>> On Wed, Aug 22, 2007 at 10:33 AM, in message
<[EMAIL PROTECTED]>, Gene LeDuc
<[EMAIL PROTECTED]> wrote:
> Hi Tim,
>
> The number of schools is small enough that I'd do it this way:
> 1. Create a group with the same name as each school (BHS in this
> case). The members of the group are the respective techs. This lets you
> scale to multiple techs at a single location or have a single tech cover
> multiple locations.
> 2. When you get the info from your LDAP query (BHS), use it to get the
> e- mail address of each member of the BHS group, then send your
notification
> to the resulting e- mail list.
> 3. As techs come and go, just update the group membership.
>
> Have fun!
> Gene
>
> At 08:04 PM 8/21/2007, Tim Wilson wrote:
>>Hi everyone,
>>
>>Our RT system is used throughout our school district which includes eight
>>different schools. Each school has its own technician who handles the vast
>>majority of tech support requests at that school. All of our RT tickets
>>feed into a central queue called "Incidents," a design decision that
>>allows our techs to help one another by dipping into the Incidents queue
>>to grab tickets when they have time.
>>
>>I just finished a scrip action that sets a custom field for each ticket in
>>the Incidents queue based on the result of an LDAP query. For example, if
>>a teacher from our high school submits a ticket, a ticket custom field
>>called "Building" gets set to "BHS".
>>
>>Now here's the issue: I'd like to notify the technician at a particular
>>school when someone from that school submits a ticket. I don't want to set
>>the tech as the ticket owner because it's possible that another tech will
>>actually grab it. And I don't want to overwhelm all the techs by notifying
>>them of every incoming ticket.
>>
>>What's the best approach?
>>
>>Would it help to create a user custom field and set that to the
building too?
>>
>>Could I use the SendEmailAction for this and create a version of the
>>template for each of the techs?
>>http://wiki.bestpractical.com/view/SendEmailAction
>>
>>I'd love to hear what some of you think.
>>
>>- Tim
>>
>>--
>>Tim Wilson, Director of Technology
>>Buffalo- Hanover- Montrose Schools
>>214 1st Ave NE Buffalo, MN 55313
>>ph: 763.682.8740 fax: 763.682.8743 http://www.buffalo.k12.mn.us
>>
>>
>>
>>
>>_______________________________________________
>>http://lists.bestpractical.com/cgi- bin/mailman/listinfo/rt- users
>>
>>Community help: http://wiki.bestpractical.com
>>Commercial support: [EMAIL PROTECTED]
>>
>>
>>Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
>>Buy a copy at http://rtbook.bestpractical.com
>
--
Tim Wilson, Director of Technology
Buffalo-Hanover-Montrose Schools
214 1st Ave NE Buffalo, MN 55313
ph: 763.682.8740 fax: 763.682.8743 http://www.buffalo.k12.mn.us
--
Gene LeDuc, GSEC
Security Analyst
San Diego State University
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
