On Wed, Aug 17, 2011 at 10:45:46AM -0400, Jeff Blaine wrote:
> This seems to have been fixed by ditching the previous
> effort to bring "all but Tickets" from our production
> database to this development host.
Oh, if I knew this was a non-stock database that's where I would have
suggested you loo
This seems to have been fixed by ditching the previous
effort to bring "all but Tickets" from our production
database to this development host.
http://www.mailinglistarchive.com/html/rt-users@lists.bestpractical.com/2011-06/msg00406.html
I will follow up to that thread with a warning to future
t
On 8/11/2011 9:22 AM, Kevin Falcone wrote:
On Wed, Aug 10, 2011 at 01:03:28PM -0400, Jeff Blaine wrote:
[Wed Aug 10 16:48:30 2011] [info]: Transaction type is 'Create' so
enabling AffectedEmployee processing stuff. ((eval 4448):24)
What code is throwing this?
One of my scrips which takes emp
On Wed, Aug 10, 2011 at 01:03:28PM -0400, Jeff Blaine wrote:
> [Wed Aug 10 16:48:30 2011] [info]: Transaction type is 'Create' so
> enabling AffectedEmployee processing stuff. ((eval 4448):24)
What code is throwing this?
-kevin
pgpzcyPHLBQHP.pgp
Description: PGP signature
RT Training S
On 8/10/2011 12:39 PM, Ruslan Zakirov wrote:
If there is only one transaction then something pushing data through
Create method. It can be callback or library, but not a scrip. List of
files in local dir may sched some light.
Gladly. More info below this, too. Note that the 2 local
callbacks
If there is only one transaction then something pushing data through Create
method. It can be callback or library, but not a scrip. List of files in
local dir may sched some light.
Regards, Ruslan. From phone.
10.08.2011 20:31 пользователь "Jeff Blaine" написал:
> A colleague has pointed out that
A colleague has pointed out that it's not just the
Discovery Method field that is being set to an
arbitrary choice (from its possible choices).
There are other fields being set as well!
RT Training Sessions (http://bestpractical.com/services/training.html)
* Chicago, IL, USA September
On 8/10/2011 11:20 AM, Kevin Falcone wrote:
On Wed, Aug 10, 2011 at 10:55:18AM -0400, Jeff Blaine wrote:
That TransactionObj isn't going to be about setting the Custom Field.
Fair enough, but I still see this which means the regexp
was not matched and the CF was not touched:
Wasn't touched b
On Wed, Aug 10, 2011 at 10:55:18AM -0400, Jeff Blaine wrote:
> >That TransactionObj isn't going to be about setting the Custom Field.
>
> Fair enough, but I still see this which means the regexp
> was not matched and the CF was not touched:
Wasn't touched by this scrip, but something must be touc
On 8/10/2011 10:08 AM, Kevin Falcone wrote:
On Wed, Aug 10, 2011 at 09:04:59AM -0400, Jeff Blaine wrote:
On 8/9/2011 5:28 PM, Kevin Falcone wrote:
On Tue, Aug 09, 2011 at 02:59:44PM -0400, Jeff Blaine wrote:
I'm confused and can't see that I am doing anything
wrong. Either I *am* doing someth
On Wed, Aug 10, 2011 at 09:04:59AM -0400, Jeff Blaine wrote:
> On 8/9/2011 5:28 PM, Kevin Falcone wrote:
> >On Tue, Aug 09, 2011 at 02:59:44PM -0400, Jeff Blaine wrote:
> >>I'm confused and can't see that I am doing anything
> >>wrong. Either I *am* doing something wrong, or there's
> >>a really b
On 8/9/2011 5:28 PM, Kevin Falcone wrote:
On Tue, Aug 09, 2011 at 02:59:44PM -0400, Jeff Blaine wrote:
I'm confused and can't see that I am doing anything
wrong. Either I *am* doing something wrong, or there's
a really bizarre bug in 3.8.10. Surely it's the former.
Since you don't say what t
On Tue, Aug 09, 2011 at 02:59:44PM -0400, Jeff Blaine wrote:
> I'm confused and can't see that I am doing anything
> wrong. Either I *am* doing something wrong, or there's
> a really bizarre bug in 3.8.10. Surely it's the former.
Since you don't say what the condition of the Scrip is, it's hard
Perhaps this is somehow related? We're seeing these
sometimes, but definitely not with each new ticket
creation:
[Tue Aug 9 19:20:17 2011] [warning]: Use of uninitialized value in
string ne at /apps/rt/bin/../lib/RT/Rule.pm line 59.
(/apps/rt/bin/../lib/RT/Rule.pm:59)
line 59 of /apps/rt/bi
In fact, if I set this scrip to 'disabled',
'Discovery Method' still gets set to a value
upon new ticket creation.
This is not happening on our RT 3.8.7 production
box. It is only happening with our 3.8.10
test instance.
On 8/9/2011 3:25 PM, Jeff Blaine wrote:
On 8/9/2011 3:07 PM, Kenneth Croc
On 8/9/2011 3:07 PM, Kenneth Crocker wrote:
Jeff,
I need more info. Are you saying the CF IS changed but a template or
email says it isn't or what. Or are you saying the CF is changed and
then gets unchanged?
'Discovery Method' is a CF of type 'multiple values' that
applies to Tickets.
The sc
Jeff,
I need more info. Are you saying the CF IS changed but a template or email
says it isn't or what. Or are you saying the CF is changed and then gets
unchanged? It isn't clear to me what is exactly happening. Also, what is it
the scrip is supposed to do? You don't shop any code that shows what
I'm confused and can't see that I am doing anything
wrong. Either I *am* doing something wrong, or there's
a really bizarre bug in 3.8.10. Surely it's the former.
The following scrip reports (as we expect in our specific
test cases):
No match, Discovery Method left alone
Old '' New ''
18 matches
Mail list logo
