[rt-users] Couldn't create related ticket create-Manager approval for ### No permission to create tickets in the queue '___Approvals' in RT 4.2

[vitalik1]

Hello Experts,

I am following these instructions 
http://www.bestpractical.com/docs/rt/4.2.0/customizing/approvals.html to create 
a simple Approval mechanism on an fresh install of RT 4.2/MySQL 5.1/RHEL 6 
system.

As the Root user I created a "Change requests" queue.
In the queue I created a new type-Perl Template called "Create approval" with 
the following code:
++
===Create-Ticket: Manager approval
Subject: Manager Approval for {$Tickets{TOP}->Id} - {$Tickets{TOP}->Subject}
Depended-On-By: TOP
Queue: ___Approvals
AdminCcGroup: vPEO
Requestors: {$Tickets{TOP}->RequestorAddresses}
Type: approval
Content-Type: text/plain
Due: {time + 3*24*60*60}
Content: Please approve me.

Thanks.
ENDOFCONTENT
++


Created a scrip "Create an approval on ticket create" Condition: "On Create", 
Action: Create Tickets, Template: "create approval", Status: "enabled".
I have left ___Approvals queue disabled.
I have added the following rights to the ___Approvals queue: Grant ShowTicket 
and ModifyTicket rights to the Owner and AdminCc roles.
I did not add vPEO group as watchers of the ___Approvals queue explicitly.
Members of the vPEO group (including Root) can create tickets in the "Change 
requests" queue, but as you can see below from the log no corresponding 
"Approvals" get created and none of the vPEO members can see anything in the 
Tools->Approval menu.

The information in /var/log/messages is below:
Nov  4 14:00:02 ddcdevsupport01 RT: [2954] Couldn't create related ticket 
create-Manager approval for 20 No permission to create tickets in the queue 
'___Approvals'
Nov  4 14:00:02 ddcdevsupport01 RT: [2954] Use of uninitialized value in 
concatenation (.) or string at /opt/rt4/sbin/../lib/RT/Action/CreateTickets.pm 
line 1151.
Nov  4 14:00:02 ddcdevsupport01 RT: [2954] Use of uninitialized value in 
concatenation (.) or string at /opt/rt4/sbin/../lib/RT/URI/fsck_com_rt.pm line 
95.
Nov  4 14:00:02 ddcdevsupport01 RT: [2954] Resolver RT::URI::fsck_com_rt could 
not parse fsck.com-rt://ddcdevsupport01.xxx.yyy.emc.com/ticket/, maybe 
Organization config was changed?
Nov  4 14:00:02 ddcdevsupport01 RT: [2954] Use of uninitialized value $id in 
hash element at /opt/rt4/sbin/../lib/RT/Ticket.pm line 1944.
Nov  4 14:00:02 ddcdevsupport01 RT: [2954] Use of uninitialized value $value in 
substitution (s///) at /opt/rt4/sbin/../lib/RT/Tickets.pm line 2698.
Nov  4 14:00:02 ddcdevsupport01 RT: [2954] Use of uninitialized value $value in 
substitution (s///) at /opt/rt4/sbin/../lib/RT/Tickets.pm line 2698.
Nov  4 14:00:02 ddcdevsupport01 RT: [2954] Use of uninitialized value in 
concatenation (.) or string at /opt/rt4/sbin/../lib/RT/Tickets.pm line 2731.
Nov  4 14:00:02 ddcdevsupport01 RT: [2954] Use of uninitialized value in 
concatenation (.) or string at /opt/rt4/sbin/../lib/RT/Tickets.pm line 2731.
Nov  4 14:00:02 ddcdevsupport01 RT: [2954] Use of uninitialized value $id in 
hash element at /opt/rt4/sbin/../lib/RT/Ticket.pm line 1957.
Nov  4 14:00:02 ddcdevsupport01 RT: [2954] Resolver RT::URI::fsck_com_rt could 
not parse fsck.com-rt://ddcdevsupport01.xxx.yyy.emc.com/ticket/, maybe 
Organization config was changed?
Nov  4 14:00:02 ddcdevsupport01 RT: [2954] RT::Link=HASH(0x7ff7917cad50) 
Couldn't resolve target 'fsck.com-rt://ddcdevsupport01.xxx.yyy.emc.com/ticket/' 
into a URI.
Nov  4 14:00:02 ddcdevsupport01 RT: [2954] Link could not be created: Couldn't 
resolve target 'fsck.com-rt://ddcdevsupport01.xxx.yyy.emc.com/ticket/' into a 
URI.
Nov  4 14:00:02 ddcdevsupport01 RT: [2954] AddLink thru 20 failed: Link could 
not be created: Couldn't resolve target 
'fsck.com-rt://ddcdevsupport01.xxx.yyy.emc.com/ticket/' into a URI.
Nov  4 14:00:02 ddcdevsupport01 RT: [2954] Use of uninitialized value in 
concatenation (.) or string at /opt/rt4/sbin/../lib/RT/Action/CreateTickets.pm 
line 1198.
Nov  4 14:00:02 ddcdevsupport01 RT: [2954] Ticket 20 created in queue 'Change 
requests' by root


Any suggestions on what is going wrong here are greatly appreciated.

Respectfully,

-Vitaly

Re: [rt-users] Integrating RT w/ SugarCRM information

[Adam Thick]

Hi Gary,

we have used a script to add client information ( from a custom field ) in RT 
based on the incoming email address.

Is this the sort of thing you're after? I imagine you could make a call in the 
middle there to get values from your CRM.

{

#test create
return 0 unless $self->TransactionObj->Type eq "Create"; #only assign on create
return 0 if $self->TicketObj->FirstCustomFieldValue('Client'); # and if there's 
no client defined already

my $ticket = $self->TicketObj;
my $cf = RT::CustomField->new($RT::SystemUser);
my $requestor = $ticket->RequestorAddresses;

$requestor =~ /(^.+)@([^\.].*\.[a-z]{2,}$)/;
# $1 returns the username, $2 returns the domain name
my $cf_value = $2;

$cf->LoadByName(Name => 'Skip Auto Assign'); #we do not want to auto assign 
some clients
my $skaa_values = $cf->Values;
return 0 if !$cf->id;

while ( my $v = $skaa_values->Next ) {
next if ! $v->Name || $v->Name eq '';
if ($v->Name eq $cf_value) {
 return 0;
   }
}

$cf->LoadByName(Name => 'Client'); #Load up the client custom field
my $cf_values = $cf->Values;
return 0 if !$cf->id;

while ( my $v = $cf_values->Next ) {
next if ! $v->Name || $v->Name eq '';
if ($v->Name eq $cf_value) {
$cf->AddValueForObject( Object => $ticket, Content => $cf_value); # if 
the incoming client matches add it to the ticket
return 1;
}
}

return 0;

}

Cheers,
Adam T.

On 03/11/2013, at 3:45 AM, Garry Glendown  wrote:

> Hi,
> 
> after using OTRS for a couple years, we're thinking about moving (back)
> to RT ... while I assume we can get the other custom stuff we set up in
> OTRS (billing information for tickets, etc.) to work, and already have
> some basic stuff (like Authentication to our internal LDAP) running, I'm
> currently looking into integrating RT with our SugarCRM database ... we
> currently get customer info  based on customer EMails (including
> customer ID, phone number, company name etc.) to display with a ticket
> in OTRS. I'd like to get this into RT ... a search on the net only came
> up with a couple other people looking for using RT instead of the
> ticketing of the CRM ...
> Does anybody have any pointers on whether and how to get this working?
> 
> Thanks, Garry
> 
> -- 
> PGP Fingerprint: A79F A33F 5B13 BEB7 A51D 274F F99C 3AE2 4BCB 7015
> 

Re: [rt-users] apache can't locate Symbol/Global/Name.pm

[Nick Price]

Hi Kevin

I used the perl that was already installed on the system
But I did update Symbol:Global:Name with cpan   to version 0.04

How do I check to see if my RT perl and mod_perl are the same

Nick



-Original Message-
From: rt-users-boun...@lists.bestpractical.com
[mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Kevin Falcone
Sent: Tuesday, November 05, 2013 22:07
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] apache can't locate Symbol/Global/Name.pm

On Sat, Nov 02, 2013 at 08:55:48PM +0100, Nick Price wrote:
>I was trying to upgrade RT from 4.0.17 to 4.2.0 on fedora 18
> 
>When I start apache I get "Can't locate  Symbol/Global/Name.pm in 
> @INC
> 
>Mod_perl was installed with yum when I first installed RT 4.0.15
update to 4.0.17 went ok
>everything worked
> 
>I did install Symbol:Global:Name with cpan   version 0.04
> 
>Mod_perl version 2.0.7

When upgrading to 4.2.0, did you use the system perl or install a custom
perl?


>His readme tells me what it does but nothing on how to install it 
> so apache can see it

That's not really the purview of a README, that's usually unix permissions
or web server configuration.  Symbol::Global::Name can be used in non-RT
contexts.

Assuming your RT perl and mod_perl perl are the same, the usual next step is
to check that the web server can read the file Symbol/Global/Name.pm found
in one of the paths referenced in the error message you truncated.

-kevin

Re: [rt-users] Create transaction content field is empty (only) when a ticket is created by the API.

[Kevin Falcone]

On Tue, Nov 05, 2013 at 05:57:26AM +, Ben Kolera wrote:
> So my long winded question is, ³Is this behaviour intended and should I
> change my automations to trawl through the transaction attachments to get
> at the Create body?². It may be noteworthy that even comments and
> correspondences from the API seem to be populating the transaction Content
> field properly when read out, so it is only the Create call, and only when
> it is done through the API; which leads me to believe (and hope!) that
> this is just an unintended bug.

This looks like a bug to me, added as part of the code to allow
text/html parts.

I'll bounce your mail into the bug tracker and comment further there.

-kevin


pgpmWqJguk0sV.pgp
Description: PGP signature

Re: [rt-users] CC emails not always being sent

[Kevin Falcone]

On Mon, Nov 04, 2013 at 01:44:58PM +, Cena, Stephen (ext. 300) wrote:
> I thought that might be the case. Is there a better way to ensure that
> CC emails are always sent? Both our Service Dept & the IT Dept will
> add users to the CC's as needed. In both RT systems, I have a "On
> Correspond Notify Others" Scrip and thought that would cover it.
> 
> What is the proper/recommended way to ensure all CC users get their emails 
> without extra emails getting generated?

On Correspond Notify CCs is the proper scrip to ensure that Ticket
CCs get their email.

On Correspond Notify other recipients is the proper scrip to ensure
that one time CCs and BCCs get their email.

Please note the difference between Ticket CCs and the one-time-CCs,
these are handled by different Scrip actions.

-kevin


pgpm0IvyPaldh.pgp
Description: PGP signature

Re: [rt-users] apache can't locate Symbol/Global/Name.pm

[Kevin Falcone]

On Sat, Nov 02, 2013 at 08:55:48PM +0100, Nick Price wrote:
>I was trying to upgrade RT from 4.0.17 to 4.2.0 on fedora 18
> 
>When I start apache I get "Can't locate  Symbol/Global/Name.pm in @INC
> 
>Mod_perl was installed with yum when I first installed RT 4.0.15  update 
> to 4.0.17 went ok
>everything worked
> 
>I did install Symbol:Global:Name with cpan   version 0.04
> 
>Mod_perl version 2.0.7

When upgrading to 4.2.0, did you use the system perl or install a
custom perl?


>His readme tells me what it does but nothing on how to install it so 
> apache can see it

That's not really the purview of a README, that's usually unix
permissions or web server configuration.  Symbol::Global::Name can be
used in non-RT contexts.

Assuming your RT perl and mod_perl perl are the same, the usual next
step is to check that the web server can read the file
Symbol/Global/Name.pm found in one of the paths referenced in the
error message you truncated.

-kevin


pgpnYFlzLBHRZ.pgp
Description: PGP signature

Re: [rt-users] RT 4.2 and ownership of tickets after comments

[Alex Vandiver]

On Tue, 2013-11-05 at 15:36 -0500, Chris Hall wrote:
> Still haven't found anything.  What's odd is that it's not a problem
> w/ the scrip.  The scrip still works.  RT force changes the owner to
> whoever made the comment.  It even shows up in the history.  But it's
> like the very next thing that happens is the new owner "gives" the
> ownership back to the original owner.  I can't seem to figure out why.

Look at your logs; I suspect you have a second scrip which is firing to
give it back.
 - Alex

Re: [rt-users] RT 4.2 and ownership of tickets after comments

[Chris Hall]

Still haven't found anything.  What's odd is that it's not a problem w/ the
scrip.  The scrip still works.  RT force changes the owner to whoever made
the comment.  It even shows up in the history.  But it's like the very next
thing that happens is the new owner "gives" the ownership back to the
original owner.  I can't seem to figure out why.


On Tue, Nov 5, 2013 at 12:32 PM, Chris Hall  wrote:

> My mistake, the custom action commit code is this:
>
> # get actor ID
> my $Actor = $self->TransactionObj->Creator;
>
> # ok, try to change owner
> $RT::Logger->info("Auto assign ticket #". $self->TicketObj->id ." to user
> #".$Actor );
> my ($status, $msg) = $self->TicketObj->SetOwner( $Actor,'Force' );
> unless( $status ) {
>   $RT::Logger->error( "Impossible to assign the ticket to $Actor: $msg" );
>   return undef;
> }
> return 1;
>
>
> On Tue, Nov 5, 2013 at 12:10 PM, Chris Hall  wrote:
>
>> This is my scrip that sets the owner to themselves after a comment.  Like
>> I said though it's working fine.  However, something else seems to be
>> kicking off now afterwards that is giving the ticket back to the previous
>> owner.
>>
>>
>> Condition: On Create
>> Action: User Defined
>> Template: Blank
>>
>> Custom Condition: 
>>
>> Custom action preparation code:
>>   return 1;
>>
>> Custom action commit code:
>>   # get actor ID
>>   my $Actor = $self->TransactionObj->Creator;
>>
>>   # if actor is RT_SystemUser then get out of here
>>   return 1 if $Actor == $RT::SystemUser->id;
>>
>>   # get out unless ticket owner is nobody
>>   return 1 unless $self->TicketObj->Owner == $RT::Nobody->id;
>>
>>   # ok, try to change owner
>>   $RT::Logger->info("Auto assign ticket #". $self->TicketObj->id ." to
>> user #".$Actor );
>>   my ($status, $msg) = $self->TicketObj->SetOwner( $Actor );
>>   unless( $status ) {
>> $RT::Logger->error( "Impossible to assign the ticket to $Actor: $msg"
>> );
>> return undef;
>>   }
>>   return 1;
>>
>>
>>
>> On Tue, Nov 5, 2013 at 12:03 PM, Alex Vandiver 
>> wrote:
>>
>>> On Tue, 2013-11-05 at 11:40 -0500, Chris Hall wrote:
>>> > I'm noticing a strange problem after my upgrade from 4.0.0 to 4.2.
>>> >  Before my upgrade I'd made a global script that would have the user
>>> > attempt to take ownership of a ticket after commenting on it.  This is
>>> > still working after the upgrade.  However, now it is immediately given
>>> > back to the previous owner for some reason.  History reads like this:
>>> >
>>> >
>>> >
>>> >
>>> > # The RT System itself - Owner forcibly changed from UserA to UserB
>>> > # UserB - Given to UserA
>>> >
>>> >
>>> > Any ideas what might be causing this and how to stop it?
>>>
>>> You will need to provide the scrip before we will be able to hazard any
>>> guesses.
>>>  - Alex
>>>
>>>
>>
>

Re: [rt-users] Scrip to add CC is not sending email

[Grant Emsley]

For anyone who comes across this in the future:

Change the notification scripts to run in the Transaction Batch stage instead 
of Transaction Create.  All the transaction create scrips are prepared, then 
they all get committed.  The notification scripts decide who to send the emails 
to in the preparation step, before the new CC has actually been committed.

The Transaction Batch stage starts after all the transaction create scrips have 
been committed, so it will see the new watcher.

-Original Message-
From: Grant Emsley 
Sent: Monday, November 04, 2013 11:02 AM
To: rt-users@lists.bestpractical.com
Subject: Scrip to add CC is not sending email

I've created a scrip based on 
http://requesttracker.wikia.com/wiki/OnCreateAddGroupCc, which automatically 
adds CCs based on a custom field.

Adding the CC works fine, and they get copied on further correspondence.  But 
they don't get the initial email like they would if I put them in the actual CC 
box when creating the ticket.
I assume what happens is all the scrips run for the initial ticket, including 
the my custom one and the one that sends emails to CCs.  But even though mine 
runs first, it still doesn't see the added CC, since that's a separate 
transaction.

I've searched for a scrip that would send the original ticket to new CC's when 
they are added, but haven't come up with anything.  How can I make sure the new 
CCs get an email when they are added by my scrip instead of the CC box during 
ticket creation?

RT version 4.2.0.  All other scrips are the default ones, nothing has been 
changed except adding mine.

In case I'm doing something wrong with my scrip, the code is below.

Thanks,

Grant Emsley




Description: 01 On Create Add Department CCs
Condition: User Defined
Action: User Defined
Template: Blank


Custom Condition:

$RT::Logger->info("On Create Add Department CCs: entering condition check"); if(
(($self->TransactionObj->Type eq "Create") || 
($self->TransactionObj->Type eq "CustomField"))
&&($self->TicketObj->FirstCustomFieldValue('Department'))
&&($self->TicketObj->FirstCustomFieldValue('Department') ne 'None')
  ) {
$RT::Logger->info("On Create Add Department CCs:  met conditions - 
Department is " . $self->TicketObj->FirstCustomFieldValue('Department'));
return 1;
  } else {
return undef;
}

Custom action preparation code:

my $groupname = 'CC-' . $self->TicketObj->FirstCustomFieldValue('Department');

# Load the custom group from RT
my $groupObj = RT::Group->new($RT::SystemUser); 
$groupObj->LoadUserDefinedGroup($groupname);
return undef unless $groupObj;

# Instead of adding the group, find and add the members of the group # This 
way, we can exclude the requestor themselves from being CC'ed.
my $groupMembersObj = $groupObj->UserMembersObj;

$RT::Logger->info("Finding members of group $groupname for ticket #" . 
$self->TicketObj->id); my $userObj; while ($userObj = $groupMembersObj->Next) {
if(($self->TicketObj->IsRequestor($userObj->PrincipalId)) or 
($self->TicketObj->IsCc($userObj->PrincipalId))) {
$RT::Logger->info("On Create Add Department CCs: Not adding " . 
$userObj->Name . ", already on ticket " . $self->TicketObj->id);
} else {
$RT::Logger->info("On Create Add Department CCs: Adding " . 
$userObj->Name . " to ticket " . $self->TicketObj->id);
my ($success, $msg) = $self->TicketObj->AddWatcher(
Type => "Cc",
PrincipalId => $userObj->PrincipalId);
if(!$success) {
$RT::Logger->info("On Create Add Department CCs: Could 
not add " . $userObj->Name . " to " . $self->TicketObj->id . "Got: " . $msg);
}
}
}
return 1;

Re: [rt-users] RT 4.2 and ownership of tickets after comments

[Chris Hall]

My mistake, the custom action commit code is this:

# get actor ID
my $Actor = $self->TransactionObj->Creator;

# ok, try to change owner
$RT::Logger->info("Auto assign ticket #". $self->TicketObj->id ." to user
#".$Actor );
my ($status, $msg) = $self->TicketObj->SetOwner( $Actor,'Force' );
unless( $status ) {
  $RT::Logger->error( "Impossible to assign the ticket to $Actor: $msg" );
  return undef;
}
return 1;


On Tue, Nov 5, 2013 at 12:10 PM, Chris Hall  wrote:

> This is my scrip that sets the owner to themselves after a comment.  Like
> I said though it's working fine.  However, something else seems to be
> kicking off now afterwards that is giving the ticket back to the previous
> owner.
>
>
> Condition: On Create
> Action: User Defined
> Template: Blank
>
> Custom Condition: 
>
> Custom action preparation code:
>   return 1;
>
> Custom action commit code:
>   # get actor ID
>   my $Actor = $self->TransactionObj->Creator;
>
>   # if actor is RT_SystemUser then get out of here
>   return 1 if $Actor == $RT::SystemUser->id;
>
>   # get out unless ticket owner is nobody
>   return 1 unless $self->TicketObj->Owner == $RT::Nobody->id;
>
>   # ok, try to change owner
>   $RT::Logger->info("Auto assign ticket #". $self->TicketObj->id ." to
> user #".$Actor );
>   my ($status, $msg) = $self->TicketObj->SetOwner( $Actor );
>   unless( $status ) {
> $RT::Logger->error( "Impossible to assign the ticket to $Actor: $msg"
> );
> return undef;
>   }
>   return 1;
>
>
>
> On Tue, Nov 5, 2013 at 12:03 PM, Alex Vandiver 
> wrote:
>
>> On Tue, 2013-11-05 at 11:40 -0500, Chris Hall wrote:
>> > I'm noticing a strange problem after my upgrade from 4.0.0 to 4.2.
>> >  Before my upgrade I'd made a global script that would have the user
>> > attempt to take ownership of a ticket after commenting on it.  This is
>> > still working after the upgrade.  However, now it is immediately given
>> > back to the previous owner for some reason.  History reads like this:
>> >
>> >
>> >
>> >
>> > # The RT System itself - Owner forcibly changed from UserA to UserB
>> > # UserB - Given to UserA
>> >
>> >
>> > Any ideas what might be causing this and how to stop it?
>>
>> You will need to provide the scrip before we will be able to hazard any
>> guesses.
>>  - Alex
>>
>>
>

Re: [rt-users] RT 4.2 and ownership of tickets after comments

[Chris Hall]

This is my scrip that sets the owner to themselves after a comment.  Like I
said though it's working fine.  However, something else seems to be kicking
off now afterwards that is giving the ticket back to the previous owner.


Condition: On Create
Action: User Defined
Template: Blank

Custom Condition: 

Custom action preparation code:
  return 1;

Custom action commit code:
  # get actor ID
  my $Actor = $self->TransactionObj->Creator;

  # if actor is RT_SystemUser then get out of here
  return 1 if $Actor == $RT::SystemUser->id;

  # get out unless ticket owner is nobody
  return 1 unless $self->TicketObj->Owner == $RT::Nobody->id;

  # ok, try to change owner
  $RT::Logger->info("Auto assign ticket #". $self->TicketObj->id ." to user
#".$Actor );
  my ($status, $msg) = $self->TicketObj->SetOwner( $Actor );
  unless( $status ) {
$RT::Logger->error( "Impossible to assign the ticket to $Actor: $msg" );
return undef;
  }
  return 1;



On Tue, Nov 5, 2013 at 12:03 PM, Alex Vandiver wrote:

> On Tue, 2013-11-05 at 11:40 -0500, Chris Hall wrote:
> > I'm noticing a strange problem after my upgrade from 4.0.0 to 4.2.
> >  Before my upgrade I'd made a global script that would have the user
> > attempt to take ownership of a ticket after commenting on it.  This is
> > still working after the upgrade.  However, now it is immediately given
> > back to the previous owner for some reason.  History reads like this:
> >
> >
> >
> >
> > # The RT System itself - Owner forcibly changed from UserA to UserB
> > # UserB - Given to UserA
> >
> >
> > Any ideas what might be causing this and how to stop it?
>
> You will need to provide the scrip before we will be able to hazard any
> guesses.
>  - Alex
>
>

Re: [rt-users] Question about 4.2 and setting the owner

[Chris Hall]

That's the answer Alex.  I found it a few minutes after I'd emailed the
mailing list.  There's ~60 users.  Thanks for the reply.


On Tue, Nov 5, 2013 at 12:03 PM, Alex Vandiver wrote:

> On Tue, 2013-11-05 at 11:35 -0500, Parish, Brent wrote:
> > Add this line into RT_SiteConfig.pm:
> >
> > Set($AutocompleteOwners, 0);
>
> RT 4.2 did not change this default; if $AutocompleteOwners was not set
> in your 4.0 installation, it will not be set in your 4.2 upgrade.
>
> You are likely running into a performance optimization in RT 4.2;
> namely, configurations with large numbers of possible Owners (generally
> due to configuration errors) can cause extremely long load times on
> Update pages.  RT 4.2 switches to the autocompleter when it finds more
> than 50 possible owners, rather than attempting to render a very large
> drop-down.  This is irrespective of the value of $AutocompleteOwners.
>
> How many potential owners exist in this queue?
>  - Alex
>
>
>

Re: [rt-users] RT 4.2 and ownership of tickets after comments

[Alex Vandiver]

On Tue, 2013-11-05 at 11:40 -0500, Chris Hall wrote:
> I'm noticing a strange problem after my upgrade from 4.0.0 to 4.2.
>  Before my upgrade I'd made a global script that would have the user
> attempt to take ownership of a ticket after commenting on it.  This is
> still working after the upgrade.  However, now it is immediately given
> back to the previous owner for some reason.  History reads like this:
> 
> 
> 
> 
> # The RT System itself - Owner forcibly changed from UserA to UserB
> # UserB - Given to UserA 
> 
> 
> Any ideas what might be causing this and how to stop it?

You will need to provide the scrip before we will be able to hazard any
guesses.
 - Alex

Re: [rt-users] Question about 4.2 and setting the owner

[Alex Vandiver]

On Tue, 2013-11-05 at 11:35 -0500, Parish, Brent wrote:
> Add this line into RT_SiteConfig.pm:
> 
> Set($AutocompleteOwners, 0);

RT 4.2 did not change this default; if $AutocompleteOwners was not set
in your 4.0 installation, it will not be set in your 4.2 upgrade.

You are likely running into a performance optimization in RT 4.2;
namely, configurations with large numbers of possible Owners (generally
due to configuration errors) can cause extremely long load times on
Update pages.  RT 4.2 switches to the autocompleter when it finds more
than 50 possible owners, rather than attempting to render a very large
drop-down.  This is irrespective of the value of $AutocompleteOwners.

How many potential owners exist in this queue?
 - Alex

[rt-users] RT 4.2 and ownership of tickets after comments

[Chris Hall]

I'm noticing a strange problem after my upgrade from 4.0.0 to 4.2.  Before
my upgrade I'd made a global script that would have the user attempt to
take ownership of a ticket after commenting on it.  This is still working
after the upgrade.  However, now it is immediately given back to the
previous owner for some reason.  History reads like this:


# The RT System itself - Owner forcibly changed from
U
serA to UserB
# U serB - Given to UserA

Any ideas what might be causing this and how to stop it?

Re: [rt-users] Question about 4.2 and setting the owner

[Parish, Brent]

Add this line into RT_SiteConfig.pm:
Set($AutocompleteOwners, 0);


From: rt-users-boun...@lists.bestpractical.com 
[mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Chris Hall
Sent: Tuesday, November 05, 2013 9:37 AM
To: rt-users
Subject: [rt-users] Question about 4.2 and setting the owner

Hello all,

I have somewhat of an aesthetics question about RT 4.2.  Back in 4.0, when my 
helpdesk people went to create a ticket, etc, they would sometimes need to 
change the owner in the basics field.  In 4.0 it was a dropdown.  In 4.2, it's 
now a typed auto-completing field. Is there a way to revert to the dropdown 
easily?

[rt-users] RT-Shredder remove users with no tickets, exclude system object?

[Josh Stompro]

Hello, could someone explain how to exclude the system object/User-1 object
from the rt-shredder command to remove all users with no tickets.

Here are the results I get when I try to run rt-shredder.

root@virt-web2:~# rt-shredder --plugin
"Users=no_tickets,1;status,enabled;replace_relations,Nobody;limit,20"
--sqldump /root/shredder-restore-users3.sql
SQL dump file is '/root/shredder-restore-users3.sql'
Next 13 objects would be deleted:
RT::User-2033 object
RT::User-1 object
RT::User-3009 object
RT::User-20387 object
RT::User-10375 object
RT::User-15815 object
RT::User-20697 object
RT::User-13253 object
RT::User-11873 object
RT::User-16755 object
RT::User-6993 object
RT::User-220 object
RT::User-20373 object
Do you want to proceed? [y/N] y

ERROR: System object was requested for deletion, shredder couldn't
do that because system would be unusable than.

Thanks
Josh

[rt-users] Question about 4.2 and setting the owner

[Chris Hall]

Hello all,

I have somewhat of an aesthetics question about RT 4.2.  Back in 4.0, when
my helpdesk people went to create a ticket, etc, they would sometimes need
to change the owner in the basics field.  In 4.0 it was a dropdown.  In
4.2, it's now a typed auto-completing field. Is there a way to revert to
the dropdown easily?