[rt-users] Need some help with suppliers
Raed El-Hames
Raed.El-Hames at daisygroupplc.com
Thu Jun 16 09:00:42 EDT 2011
Bart,
The scrip on that page is very similar to the one I used,to push the correspondence into the ticket,
Before the while:
my $update = $self->TransactionObj->Content();
during the while loop add:
$l->BaseObj->Comment(Content=> "$update"); #or something similar ..
Regards;
Roy
From: pleh.info at gmail.com [mailto:pleh.info at gmail.com] On Behalf Of Bart
Sent: 16 June 2011 10:40
To: Raed El-Hames
Cc: rt-users at lists.bestpractical.com
Subject: Re: [rt-users] Need some help with suppliers
Hi,
Was this the sample script you used on the wiki?
http://requesttracker.wikia.com/wiki/OpenDependantsOnResolve
Best regards,
Bart
2011/6/16 Raed El-Hames <Raed.El-Hames at daisygroupplc.com<mailto:Raed.El-Hames at daisygroupplc.com>>
Hi Bart,
The scrip that trickle the update from one ticket to another is something I've written,
I don't have my rt available to me at the moment , if you need it drop me a note so I can send it to you when I can, If I remember rightly there was a very similar example scrip on the RT wiki.
Regards;
Roy
From: pleh.info<http://pleh.info>@gmail.com<http://gmail.com> [mailto:pleh.info at gmail.com<mailto:pleh.info at gmail.com>] On Behalf Of Bart
Sent: 15 June 2011 20:36
To: Raed El-Hames
Cc: rt-users at lists.bestpractical.com<mailto:rt-users at lists.bestpractical.com>
Subject: Re: [rt-users] Need some help with suppliers
Hi Roy,
That sounds like a very clean solution :-)
We were already looking at maybe just using our regular e-mail client for mailing towards the suppliers with RT on the CC but your solution would allow us to really do everything from within RT + I like the idea of making a separate ticket for the supplier.
Is the scrip you use something default within RT (can't check it atm but will do next thing tomorrow).
Anyway, thanks for the info I'll be sure to give it a try.
Best regards,
Bart
2011/6/15 Raed El-Hames <Raed.El-Hames at daisygroupplc.com<mailto:Raed.El-Hames at daisygroupplc.com>>
Bart:
The way I deal with the scenario below is as follow:
1- Customer ticket about their issue with customer as requestor
2- Create depends on ticket to the supplier with the supplier as a requestor
3- We put the customer ticket to status 'on-hold' which we added to the inactive status list
4- We have a scrip that pushes updates from depends on ticket to the Depended on By as comments (it also changes the ticket status to open) , so when the supplier reply back with the solution etc, this update is trickled into the main customer ticket and the customer ticket becomes active again.
Hope that helps.
Regards;
Roy
From: rt-users-bounces at lists.bestpractical.com<mailto:rt-users-bounces at lists.bestpractical.com> [mailto:rt-users-bounces at lists.bestpractical.com<mailto:rt-users-bounces at lists.bestpractical.com>] On Behalf Of Bart
Sent: 15 June 2011 07:07
To: rt-users at lists.bestpractical.com<mailto:rt-users at lists.bestpractical.com>
Subject: Re: [rt-users] Need some help with suppliers
Hi,
Our suppliers use different systems and the people dealing with them is our supportdesk. So basically any ticket from our supportdesk "could" rely on an action from our suppliers.
Creating a "depends on" ticket and giving the supplier a user which becomes owner of that ticket could do it, or we could at least make them requestor for that ticket in order to mail them. I think requestor is the best case for us, the main function we need is the ability to mail towards someone else other then the requestor in the "To" field. (I'll explain below)
Something I haven't mentioned, the usual fllow with our supplier is that incidents are called in. So we write down that we've called them + I can make a CF or something like that specifying that it's now with that supplier.
But changes are things that we e-mail towards our suppliers (sometimes incidents too), and that specific action isn't possible by default. You can only mail a requestor + CC a few people (or make a comment and CC that towards someone). In that context the CC option is a problem for us since suppliers expect them to be mailed directly (CC usually means, read but don't do anything).
We could talk to them about it but I want to avoid it and use mail the way it should be used ;)
Best regards,
Bart
2011/6/14 Kenneth Crocker <kfcrocker at lbl.gov<mailto:kfcrocker at lbl.gov>>
Bart,
Do all your suppliers have RT? If not, then who in your organization deals with the suppliers? Perhaps creating a "Child/DependsOn" ticket that is owned by the person dealing with that particular supplier would work.
Just a thought.
Kenn
LBNL
On Tue, Jun 14, 2011 at 5:04 AM, Bart <bart at pleh.info<mailto:bart at pleh.info>> wrote:
Hi,
I need some help understanding the flow of tickets in RT, specifically how to work with suppliers.
In our test setup one questing came forth about sending a ticket to a supplier and how to go about it.
Lets say we have a customer sending us an incident ticket. The incident ends up being the problem of our supplier so we need to have the ticket depend on a suppliers actions.
Our current setup is pretty much default with two queue's for internal departments:
* Queues:
* Servicedesk: All new e-mails go to this queue.
* Tech support: Thirdline support for the servicedesk.
* CF's:
* A few under users for easy selection of organizations.
* And a few for the tickets for selecting to what categorie a ticket belongs to.
* In addition I've installed the SLA plugin with two test SLA's.
In our old system we would do these things by assigning a ticket to a supplier, does that mean that I would need to create a queue for each supplier that we work with for this to work?
I'm guessing "yes", hoping "no", for some suppliers having a queue is ok but for allot of other ones it's not ok. We work for the government, some direct suppliers are easy to write down as a queue but sometimes a townhall needs to fix something which would mean that we have to add roughly 450 queue's (one for each townhall).
Anyway, if someone could help me understand how to work with suppliers then I'd be extremely gratefull.
Best regards,
Bart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20110616/e2578f14/attachment.htm>
More information about the rt-users
mailing list