Re: [rt-users] Scrips and Recipients section not picking up TransactionBatch scrips - 3.8.8
I addressed this problem in one RT installation by adding a TransactionCreate script on the same condition that did nothing (using template Blank). That way you'll get the list of people that it will mail to, though not the actual template that it will use. -Chuck -- Chuck Boeheim [::] CIT [::] Systems Services Sufficient unto the day are the meetings thereof On Jul 15, 2010, at 6:19 AM, Justin Hayes wrote: That makes quite a bit of sense Roy. I'm only really interested in giving people some idea about who's going to be getting standard automated responses, so I should probably look at switching some scrips back to TransactionCreate where possible. As for my performance problems, hopefully my guy's going to be trying some of the settings you sent me, as there are lots of innoDB configs in there that we've not set at all. Hopefully we'll get somewhere. Cheers, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com<mailto:justin.ha...@openbet.com> On 15 Jul 2010, at 11:10, Raed El-Hames wrote: Hi Justin; > I've noticed that the 'Scrips and Recipients' section of the Ticket update > page doesn't pick up scrips that are TransactionBatch. Only TransactionCreate > ones are shown. This is just pure guess on my part, but I think you don’t see the list of recipients with TransactionBatch because its not possible to determine the list until you hit submit, because its possible there will be scrips that depends on other scrips or actions, eg scrip 1 on correspondence update custom field 1 if the word ‘hello’ is in the update, scrip 2 on if custom field 1 changed email b...@blah So you see its not possible to determine b...@blah will be emailed until the Transaction is created. As I said, this is my guess, possibly some one from BP can confirm. Roy Ps:how did you get on with the performance issue you had? From: rt-users-boun...@lists.bestpractical.com<mailto:rt-users-boun...@lists.bestpractical.com> [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Justin Hayes Sent: 15 July 2010 07:49 To: Kenneth Crocker Cc: rt-users@lists.bestpractical.com<mailto:rt-users@lists.bestpractical.com> Subject: Re: [rt-users] Scrips and Recipients section not picking up TransactionBatch scrips - 3.8.8 I normally do - I think I must have changed this one early on in the process before I got used to altering RT_SiteConfig.pm. So the problem still stands - I'm surprised no-one else has seen this before, unless not many people use Batch? Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com<mailto:justin.ha...@openbet.com> On 13 Jul 2010, at 19:36, Kenneth Crocker wrote: Justin, Yep. But I'd make the change in RT_SiteConfig.pm. I like to leave original files/info alone in case I ever need to reference an original setting, etc. RT will automatically override the setting from the RT_SiteConfig.pm file. Kenn LBNL On Tue, Jul 13, 2010 at 8:59 AM, Justin Hayes mailto:justin.ha...@openbet.com>> wrote: Is that this one Kenn? RT_Config.pm:Set($UseTransactionBatch, 1); Cheers, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com<mailto:justin.ha...@openbet.com> On 13 Jul 2010, at 16:52, Kenneth Crocker wrote: Justin, I hate to ask, but did you make sure your configuration setting is for Batch? Kenn LBNL On Tue, Jul 13, 2010 at 8:03 AM, Justin Hayes mailto:justin.ha...@openbet.com>> wrote: I've noticed that the 'Scrips and Recipients' section of the Ticket update page doesn't pick up scrips that are TransactionBatch. Only TransactionCreate ones are shown. I use TransactionBatch a lot of the time (I'm seem to remember their being good reasons for this) and so I can't actually see who's going to be sent mails. Does anyone know if this is a known bug/issue or deliberate? I've not found anything on the wiki Thanks, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com<mailto:justin.ha...@openbet.com> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com<http://rtbook.bestpractical.com/> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com<http://rtbook.bestpractical.com/> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com<http://rtbook.bestpractical.com/> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] RT Mobile for iPhone (Dustin Collins)
Likewise. We use webauth in front of RT, so we need to authenticate to another web page first, and then return a cookie with the transactions. -Chuck On Jun 25, 2010, at 3:02 AM, "Bartelt, John E." wrote: > I bought it but I can't get it to connect. > (1) Does it understand https? > (2) Does it understand external authentication? > > John Bartelt > > Date: Thu, 24 Jun 2010 17:56:30 -0400 > From: Dustin Collins > To: "rt-users@lists.bestpractical.com" > > Subject: [rt-users] RT Mobile for iPhone > Message-ID: <-2996965792844...@unknownmsgid> > Content-Type: text/plain; charset=ISO-8859-1 > > This is an RT client for iPhone. Check it out if your interested. > > http://itunes.apple.com/us/app/rt-mobile/id377642006?mt=8 > > > Discover RT's hidden secrets with RT Essentials from O'Reilly Media. > Buy a copy at http://rtbook.bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Workflow and ticket/task visibility
I designed a workflow for server installation while at the Stanford Linear Accelerator (SLAC), which I contributed to the RT Wiki: http://wiki.bestpractical.com/view/WorkFlow. It consists of a master ticket for the tasks, child tickets assigned automatically to the responsible groups for subtasks, and updating of the parent ticket as the subtasks are completed. A saved search gave a dashboard of all outstanding tasks and where they stood in the process. Is that the sort of thing you are looking for? -Chuck -- Chuck Boeheim [::] CIT [::] Systems Services Cheap hardware isn't On Mar 23, 2010, at 7:10 PM, Forrest Aldrich wrote: One problem I frequently run into while using RT is the issue of "workflow". There are "priority" levels, but when you have a task that has multiple people involved, it would be useful to have multiple ticket owners where when one task is completed, it's automatically punted to the next person to complete (the key being visibility). Yes, you can just re-assign the ticket - but sometimes that's not politically pleasant (office politics). A generic example: I'm asked to upgrade a server software component (product) that is used internally for which I have no other involvement; dev people are responsible for testing and Q/A of the install. I get a ticket to perform the update, I report this update as being completed, but never receive a response or approval that they found the work acceptable. So, I just close the ticket. This creates several problems, some of which are connected to the absence of a workflow process. Anyway, I wonder how others in differently-sized organizations handle this type of issue within the RT framework. We are now testing a 'kanban' system internally, to see if that will help with some of these processes. Thanks... Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Tickets for multiple groups
Thanks for the response, Kenn, but I don't think that describes this particular problem. I'm concerned with the case where you might like to have a ticket show up in two queues, and updates be seen by the union of the watchers of those two queues. For instance, we have queues for the windows team, the unix team, and the security team. Most problems are within one problem domain, but some tickets are unix security problems, or unix-windows interoperability, er, opportunities. Each team looks at the list of open tickets in their own queue, but it would be nice if some tickets could show up in two queues. -Chuck On Jun 18, 2008, at 1:25 PM, Kenneth Crocker wrote: Chuck, We have over 100 technical support queues. Many of them part of the same overall support group, but a different software application. We offer to the users of each application the email address for only the queue they would send a request to for 'that' application. Some "groups" have a central queue where requests for several software applications go and there they are evaluated, approved, prioritized before being moved to the specific queue that supports that specific software. We control all that by using very few global privileges (just those that we want to apply to roles, like requestors, regardless of queue) putting most of the restrictions on the queue level and we allow NO privileges to individual users (except 2 superusers, who act as System Admins). All users are in specific groups and those groups are limited in access to queues by the privileges at that queue level. Hope this helps. Kenn LBNL On 6/17/2008 9:01 AM, Chuck Boeheim wrote: Hi Folks, We've been using RT for some years, but now with a decision to ditch Remedy and move all groups to RT, we're getting quite a few new queues. This has caused the situation to arise where some tickets fall into the cracks between groups. A user might send email to the addresses for the Unix team and the Security team, because it's a unix security issue, for instance. Because there's only one underlying email address and a procmail script that picks a queue for it to go into based on email address, one of those addresses 'wins'. The falling-into-cracks happens when staff sees both addresses on the ticket but don't realize the other team hasn't seen it and don't realize they have an action item. How do other organizations handle this? The case where it's in the wrong queue is easy: just transfer the ticket to the right queue and the scrip notifies the new watchers. When it really is something that both sets of watchers should watch, then it gets tricky. We've thought of: 1) Have the procmail script create duplicate tickets in each queue. All watchers get notified, but don't see correspondence in the other queue. Putting 'related' links in the tickets only helps a small amount. 2) Put the ticket in one main queue and a child ticket in the other queue to notify watchers there is something to watch. Then there's a placeholder and a click-through link to the real ticket. There's no notification of updates to the watchers of the other queue, though. 3) Put in enough handshaking between the procmail script and an on- create scrip to add the watchers of the second queue to the ticket. All the right people get notified then, but someone who is working from the web UI don't see it in the second queue. (Our "dispatch" people tend to work from the web UI, while solvers not on duty tend to rely on watcher email.) 4) Go to a single queue, add a multi-valued custom field 'area' that contains the former queue names, can be used for searching and subsetting, and with some programming can maintain the right set of watchers on each ticket. This is a fair bit of programming to re- invent queue functionality. None of these is ideal, though 3 perhaps comes closest. Has anyone thought of a more inventive approach for supporting multiple teams who generally have separate work queues but must sometimes collaborate on solving tickets? Best, -Chuck Boeheim Stanford Linear Accelerator Center ___ 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 smime.p7s Description: S/MIME cryptographic signature ___ 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
[rt-users] Tickets for multiple groups
Hi Folks, We've been using RT for some years, but now with a decision to ditch Remedy and move all groups to RT, we're getting quite a few new queues. This has caused the situation to arise where some tickets fall into the cracks between groups. A user might send email to the addresses for the Unix team and the Security team, because it's a unix security issue, for instance. Because there's only one underlying email address and a procmail script that picks a queue for it to go into based on email address, one of those addresses 'wins'. The falling-into-cracks happens when staff sees both addresses on the ticket but don't realize the other team hasn't seen it and don't realize they have an action item. How do other organizations handle this? The case where it's in the wrong queue is easy: just transfer the ticket to the right queue and the scrip notifies the new watchers. When it really is something that both sets of watchers should watch, then it gets tricky. We've thought of: 1) Have the procmail script create duplicate tickets in each queue. All watchers get notified, but don't see correspondence in the other queue. Putting 'related' links in the tickets only helps a small amount. 2) Put the ticket in one main queue and a child ticket in the other queue to notify watchers there is something to watch. Then there's a placeholder and a click-through link to the real ticket. There's no notification of updates to the watchers of the other queue, though. 3) Put in enough handshaking between the procmail script and an on-create scrip to add the watchers of the second queue to the ticket. All the right people get notified then, but someone who is working from the web UI don't see it in the second queue. (Our "dispatch" people tend to work from the web UI, while solvers not on duty tend to rely on watcher email.) 4) Go to a single queue, add a multi-valued custom field 'area' that contains the former queue names, can be used for searching and subsetting, and with some programming can maintain the right set of watchers on each ticket. This is a fair bit of programming to re-invent queue functionality. None of these is ideal, though 3 perhaps comes closest. Has anyone thought of a more inventive approach for supporting multiple teams who generally have separate work queues but must sometimes collaborate on solving tickets? Best, -Chuck Boeheim Stanford Linear Accelerator Center ___ 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
Re: [rt-users] Where are attachments stored?
Why not just update them as a comment, which will not re-open the
ticket?
Alternately, you could just disable the global scrip that
re-opens the tickets while you reload.
-Chuck Boeheim, SLAC
On Apr 10, 2008, at 1:39 PM, Aaron Sallade wrote:
> My concern on that is the timestamp for Resolved and how it impacts
> reporting :(
>
> I am going to try to disable the scrips and see if it works.
>
> Aaron Sallade'
> Application Manager
> PTSO of Washington
> "Shared Technology for Community Health"
> (206) 613-8938 Desk
> (206) 521-8833 Main
> (206) 613-5078 Fax
> [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Gene LeDuc [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 10, 2008 1:30 PM
> To: Aaron Sallade
> Cc: rt-users@lists.bestpractical.com
> Subject: RE: [rt-users] Where are attachments stored?
>
> Hi Aaron,
>
> Good call on the import method - that way RT gets to do all the grunt
> work. Consider creating a scrip that fires when a ticket is reopened
> (status changes from resolved to open) and then (quietly) reset it to
> resolved. Just enable the scrip when your external script is going to
> be
> e-mailing attachments to RT. This ought to be pretty straightforward.
> I
> would do the status reset using
>$self->TicketObj->_Set(Field=>'Status', Value=>'resolved',
> RecordTransaction=>0);
> rather than
>$self->TicketObj->SetStatus('resolved');
> to avoid triggering any "On Resolve" scrips.
>
> Regards,
> Gene
>
> At 01:05 PM 4/10/2008, Aaron Sallade wrote:
>> Hmm,
>>
>> I wrote a script that can email the attachments to RT with the proper
>> Ticked ID format in the header, my concern is :
>>
>> We just finished our import of data from the legacy system and have
>> about 15,000 tickets that are resolved, but do not have their
>> attachments added. If I add them via email, it will open the ticket.
>>
>> If I can find out how to not change the status or the resolved date
>> by
>> commenting out a portion of the code that handles ticket replies,
>> then
>> it could work.
>>
>> Aaron Sallade'
>> Application Manager
>> PTSO of Washington
>> "Shared Technology for Community Health"
>> (206) 613-8938 Desk
>> (206) 521-8833 Main
>> (206) 613-5078 Fax
>> [EMAIL PROTECTED]
>>
>> -Original Message-
>> From: Kenneth Crocker [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, April 10, 2008 12:45 PM
>> To: Gene LeDuc
>> Cc: Aaron Sallade; rt-users@lists.bestpractical.com
>> Subject: Re: [rt-users] Where are attachments stored?
>>
>> Gene, Aaron,
>>
>>
>>Not only that, but the content is stored in various ways,
>> depending on
>> the CONTENTTYPE field (text, message, excell, etc.) AND if you have
>> ORACLE, CONTENTCODING is not supported (at least up to 9). I built my
>> own Data Dictionary on the ORACLE version of the RT DataBase so I
>> would
>> know what to do if I was gonna update the DB via SQL or something.
>> Fooling around with creating or deleting records is more than a bit
>> tricky external to RT tools. Like I didn't know that ALL users have a
>> group id record JUST for their individual user ID. It is usually the
>> User ID plus 1. Anyway, like Gene said, not a trivial exercise.
>>
>> Kenn
>> LBNL
>>
>> On 4/10/2008 11:45 AM, Gene LeDuc wrote:
>>> Aaron, the attachments are stored in RT's database in a table called
>>> 'Attachments'. There is a field called 'Content' that holds the
> ones
>>> and zeros that make up the attachment. I suspect that importing
> files
>>
>>> into RT as ticket attachments will be a non-trivial exercise.
>>>
>>> Regards,
>>> Gene
>>>
>>> At 11:02 AM 4/10/2008, Aaron Sallade wrote:
>>>> I need to import attachments into our RT from our legacy system.
> How
>>>> are attachments stored in RT?
>>>>
>>>> Aaron Sallade'
>>>> Application Manager
>>>> PTSO of Washington
>>>> /"Shared Technology for Community Health"
>>>> /(206) 613-8938 Desk
>>>> (206) 521-8833 Main
>>>> (206) 613-5078 Fax
>>>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>>>>
>>>
>>>
>>> --
>>> Gene LeDuc, GSEC
>>> Security Analyst
>>> San Diego State University
>>>
>>>
>>>
>> -
[rt-users] Finding users to shred
Hi Folks, Does anyone have a query or a script that can find users in the database who aren't referenced by any tickets? I'd like to find users who were created by spam who are now candidates for shredding. Regards, -Chuck Boeheim ___ 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
Re: [rt-users] Can I restrict autoreplies to the local domain?
We use a second queue for this purpose. In our procmail script that feeds RT, we detect email that shouldn't get an autoreply and feed it to the alternate queue. That queue has an "On Create" script that simply changes the queue to the main support queue. There is an autoreply action only on the main support queue, not on the secondary queue. As well, you can have different, or no, watchers on the secondary queue if you are also trying to reduce possibly noise email to your watchers. Chuck Boeheim [EMAIL PROTECTED] On Sep 19, 2006, at 3:16 AM, Andreas Putzo wrote: Hi, On Sep 19, Chris Wenn wrote: Has anyone got a way of restricting RT's autoreply function to a single domain? I don't want users outside rbg.vic.gov.au to receive communication from my RT system. It's v3.4.4, running on Ubuntu Dapper 6.06, with postfix, apache2 and mysql as the backend. Chris If you have a little knowledge of perl you may take a look at lib/RT/Action/SendEmail.pm. Should not be too hard to match $TO against your domain name and either rewrite the address or discard it. This would be a nice feature IMO. Perhaps using postfix's canonical maps may work, too. But i am not sure whether it is possible to rewrite TO only if From matches your RT email address. -- regards, Andreas Putzo ___ 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 ___ 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
