In tracking the history of an Asset it would be useful to
include in the transactions, tickets that are linked to the
asset.
One way to do this would be to look at all RT::Ticket create
and link transactions and if the ticket is linked to the
asset then include it in the history. This sounds like it
would be really slow.
A better option might be to hook into the RT:Ticket Create
and AddLink subs so that when an Asset is linked to, a
transaction for that Asset can be created showing that
it is linked to a ticket.
Assuming option 2 is better, how would I go about this? If
I create Ticket_Vendor.pm how do I redefine Create and still
have access to the original Create? What I want to do is
call the original Create and if it is successful, check if
the ticket is linked to an asset. If so, create a transaction
for that asset.
Thanks.
-Todd
Still looking for advice on this, but I have a solution
that is working (option 2). I defined Ticket_Vendor.pm like so:
package RT::Ticket;
use strict;
no warnings qw(redefine);
my $Orig_AddLink = &_AddLink;
*_AddLink = sub {
my $self = shift;
my ($linkid, $msg) = $Orig_AddLink->($self, @_);
return ($linkid, $msg) unless $linkid;
my $linkObj = RT::Link->new( $self->CurrentUser );
my ($LinkId, $Msg) = $linkObj->Load($linkid);
$LinkId or return ($linkid, $msg);
my $TargetObj = $linkObj->TargetObj();
my $BaseObj = $linkObj->BaseObj();
return ($linkid, $msg) unless (ref $BaseObj eq 'RT::Ticket');
if (ref $TargetObj eq 'RTx::AssetTracker::Asset') {
$TargetObj->_NewTransaction(
Type => 'TicketLink',
NewValue => $BaseObj->Id,
);
}
return ($linkid, $msg);
};
1;
The only catch is that I had to patch RT to always return
the link id from _AddLink, which is probably the way it
should be. If not, I’ll have to come up with another solution.
-Todd
Jesse, do you have an opinion?On Thu, Feb 17, 2005 at 06:46:21PM -0500, Todd Chapman wrote:
Still looking for advice on this, but I have a solution
that is working (option 2). I defined Ticket_Vendor.pm like so:
package RT::Ticket;
use strict;
no warnings qw(redefine);
my $Orig_AddLink = &_AddLink;
*_AddLink = sub {
my $self = shift;
my ($linkid, $msg) = $Orig_AddLink->($self, @_);
return ($linkid, $msg) unless $linkid;
my $linkObj = RT::Link->new( $self->CurrentUser );
my ($LinkId, $Msg) = $linkObj->Load($linkid);
$LinkId or return ($linkid, $msg);
my $TargetObj = $linkObj->TargetObj();
my $BaseObj = $linkObj->BaseObj();
return ($linkid, $msg) unless (ref $BaseObj eq 'RT::Ticket');
if (ref $TargetObj eq 'RTx::AssetTracker::Asset') {
$TargetObj->_NewTransaction(
Type => 'TicketLink',
NewValue => $BaseObj->Id,
);
}
return ($linkid, $msg);
};
1;
The only catch is that I had to patch RT to always return
the link id from _AddLink, which is probably the way it
should be. If not, I’ll have to come up with another solution.
-Todd
Rt-devel mailing list
Rt-devel@lists.bestpractical.com
The rt-devel Archives
Jesse, do you have an opinion?
Been kinda busy. I haven’t deleted the mail.
Assuming option 2 is better, how would I go about this? If
I create Ticket_Vendor.pm how do I redefine Create and still
have access to the original Create? What I want to do is
call the original Create and if it is successful, check if
the ticket is linked to an asset. If so, create a transaction
for that asset.
Hook::LexWrap with a post-hook might be the right thing here. You might
also be able to find the right transactions using a limit/join
invocation
Hi,
is there a quick fix for disabling the /Search/Build.html to display all
possible users of the system as Owners of tickets?
We have a huge amount of those…and it significantly slows down the system.
I would like to see only privileged users.
Ah, and it’s urgent, I switched production. Lol.
cheers
Alex
Hi,
is there a quick fix for disabling the /Search/Build.html to display all
possible users of the system as Owners of tickets?
We have a huge amount of those…and it significantly slows down the system.
I would like to see only privileged users.
I can’t duplicate this error, though you’re the second person who’s
reported it. Did you upgrade this server to 3.4 or did it start off
with a clean install and an import? If it’s the former, try making sure
that /opt/rt3/var/mason_data/obj is clean and that you stop and start
the webserver. Failing that, can you capture the SQL queries RT does
for a single request of Build.html and send them alog?
Jesse
We upgraded from 3.2.2 and saw this problem. The below patch (credit to
Kent Lee) worked around it for us (warning: whitespace damaged).
I do wonder if you folks have granted “Everyone” the right to OwnTicket.
We upgraded from 3.2.2 and saw this problem. The below patch (credit to
Kent Lee) worked around it for us (warning: whitespace damaged).
I do wonder if you folks have granted “Everyone” the right to OwnTicket.
Bingo.
Everyone’s rights:
CommentOnTicket
CreateTicket
ModifySelf
ModifyTicket
OwnTicket
ReplyToTicket
ShowTicketComments
Watch
Feedback on (in)sanity of above?
Phil
I do wonder if you folks have granted “Everyone” the right to OwnTicket.
Bingo.
Everyone’s rights:
CommentOnTicket
CreateTicket
ModifySelf
ModifyTicket
OwnTicket
ReplyToTicket
ShowTicketComments
Watch
Feedback on (in)sanity of above?
I think you want to grant those rights to privileged users and give
everyone ownly create ticket, comment on ticket, reply to ticket.
Everyone means your end-users too.
I think you want to grant those rights to privileged users and give
everyone ownly create ticket, comment on ticket, reply to ticket.
Everyone means your end-users too.
Thanks, owner dropdown now much smaller 
Phil
I do wonder if you folks have granted “Everyone” the right to OwnTicket.
Not globally, at least. Might be one or the other queue has that (though
not the ones I looked into quickly).
However, I will dive into that tomorrow morning.
I helped myself very very quickly(*) with…
$Users->WhoHaveRight(Right => ‘SeeCustomField’…
which reflects 80% of the users in the system; “LimitToPrivileged” does
the trick much better…
btw. I created a “localized” version of the SelectOwner, which works
quit well.
(in /opt/rt3/local…)
To answer the other question - I did a setup on the same box, but in a
distinct directory and with a new db; I transferred all data from old_db
to new_db, ran the upgrade scripts and fixed the apache + postfix + my
nifty xml-email-to-rt-script.
This worked all well and the only two things I encountered so far as
problems in “the logic” were the custom fields, because the groups did
not have by default the right to see/edit them and the Owner Problem.
That was a bitt annoying, as it basically killed the system…our people
work frequently in the Jumbo setting, and if 8 guys in parallel retrieve
a web form with a select featuring some 10k entries…you see the point.
Thanks to you guys for the quick answers, I will stay with the proposed
Patch until I understand which rights have been given in the system by
my colleagues.
cheers
Alex
- After finding the SelectOwner Element. Took one hour or so
Top posting, on the other hand, makes your mail really hard to follow
alot of the time.
So you think the idea of creating an asset transaction when
a ticket link transaction happens is sound?
I don’t think it’s a bad idea.> On Tue, Feb 22, 2005 at 02:42:40AM -0500, Jesse Vincent wrote:
Assuming option 2 is better, how would I go about this? If
I create Ticket_Vendor.pm how do I redefine Create and still
have access to the original Create? What I want to do is
call the original Create and if it is successful, check if
the ticket is linked to an asset. If so, create a transaction
for that asset.
Hook::LexWrap with a post-hook might be the right thing here. You might
also be able to find the right transactions using a limit/join
invocation
Thanks.
-Todd
Rt-devel mailing list
Rt-devel@lists.bestpractical.com
The rt-devel Archives
–
So you think the idea of creating an asset transaction when
a ticket link transaction happens is sound?On Tue, Feb 22, 2005 at 02:42:40AM -0500, Jesse Vincent wrote:
Assuming option 2 is better, how would I go about this? If
I create Ticket_Vendor.pm how do I redefine Create and still
have access to the original Create? What I want to do is
call the original Create and if it is successful, check if
the ticket is linked to an asset. If so, create a transaction
for that asset.
Hook::LexWrap with a post-hook might be the right thing here. You might
also be able to find the right transactions using a limit/join
invocation
Thanks.
-Todd
Rt-devel mailing list
Rt-devel@lists.bestpractical.com
The rt-devel Archives
–
At Tuesday 2/22/2005 04:17 PM, Jesse Vincent wrote:
I do wonder if you folks have granted “Everyone” the right to OwnTicket.
I think you want to grant those rights to privileged users and give
everyone ownly create ticket, comment on ticket, reply to ticket.
Everyone means your end-users too.
This component (the owner drop-down) has been a problem for us at MIT too
(30s to display the search page and the bulk ticket update page). We do
have many potential owners of tickets - there are many groups using RT to
field help requests. It seems like the component doesn’t scale too well.
One thing I noticed is that SelectOwner sorts the collection of User
objects by name after it has retrieved it - in my command-line tests, this
more than doubles the time for the SelectOwner logic - the sort seems
unnecessary though, as the collection (by default) is already sorted by
name. Removing the sort certainly speeds things up a bit and gives the same
result.
Another question too, about this line on the search page. The SelectOwner
component is attached to the line which begins with a drop down containing
“Owner”, “Creator” and “LastUpdatedBy”. So is it appropriate to show a list
of potential owners, if the user may want to do a query on Creator?
Mightn’t there be potential ticket creators who don’t have OwnTicket
privileges?
Steve
At Tuesday 2/22/2005 04:17 PM, Jesse Vincent wrote:
I do wonder if you folks have granted “Everyone” the right to
OwnTicket.
I think you want to grant those rights to privileged users and give
everyone ownly create ticket, comment on ticket, reply to ticket.
Everyone means your end-users too.
This component (the owner drop-down) has been a problem for us at MIT too
(30s to display the search page and the bulk ticket update page). We do
have many potential owners of tickets - there are many groups using RT to
field help requests. It seems like the component doesn’t scale too well.
So. I have users demanding that “SelectOwner” be switched to a text
entry box and users demanding that it not be switched to a text entry
box. Not sure I have a good answer.
One thing I noticed is that SelectOwner sorts the collection of User
objects by name after it has retrieved it - in my command-line tests, this
more than doubles the time for the SelectOwner logic - the sort seems
unnecessary though, as the collection (by default) is already sorted by
name. Removing the sort certainly speeds things up a bit and gives the same
result.
Not in all cases, at least historically. SelectOwner can take multiple
objects which would result in unordered lists.
Another question too, about this line on the search page. The SelectOwner
component is attached to the line which begins with a drop down containing
“Owner”, “Creator” and “LastUpdatedBy”. So is it appropriate to show a list
of potential owners, if the user may want to do a query on Creator?
Mightn’t there be potential ticket creators who don’t have OwnTicket
privileges?
yep. and the advanced tab will work fine for that.
At Wednesday 2/23/2005 02:43 PM, Jesse Vincent wrote:>On Wed, Feb 23, 2005 at 02:29:09PM -0500, Stephen Turner wrote:
This component (the owner drop-down) has been a problem for us at MIT too
(30s to display the search page and the bulk ticket update page). We do
have many potential owners of tickets - there are many groups using RT to
field help requests. It seems like the component doesn’t scale too well.
So. I have users demanding that “SelectOwner” be switched to a text
entry box and users demanding that it not be switched to a text entry
box. Not sure I have a good answer.
Sorry if I came across as demanding - not my intention. I do think it’s a
valid issue though, one that warrants some investigation.
What I’d like to see is the drop-down list executing quickly - we have
3.1.14 running (with mysql) with very fast response on the search page.
3.4.1 against the same data (with Oracle) is considerably slower. I’ve
tried to dig into the code to see what might be causing the slowdown but
I’ve not been able to track it down.
Thanks,
Steve
At Wednesday 2/23/2005 02:43 PM, Jesse Vincent wrote:
This component (the owner drop-down) has been a problem for us at MIT too
(30s to display the search page and the bulk ticket update page). We do
have many potential owners of tickets - there are many groups using RT to
field help requests. It seems like the component doesn’t scale too well.
So. I have users demanding that “SelectOwner” be switched to a text
entry box and users demanding that it not be switched to a text entry
box. Not sure I have a good answer.
Sorry if I came across as demanding - not my intention. I do think it’s a
valid issue though, one that warrants some investigation.
Sorry. “demanding” wasn’t meant to imply that anyone was doing anything
wrong, but that there are conflicting requirements Do note that SelectOwner
changed in 3.4.0rc6. It was completely reimplemented and at least on postgres was 2
OOM faster.
What I’d like to see is the drop-down list executing quickly - we have
3.1.14 running (with mysql) with very fast response on the search page.
What about mysql with 3.4.1?
3.4.1 against the same data (with Oracle) is considerably slower. I’ve
tried to dig into the code to see what might be causing the slowdown but
I’ve not been able to track it down.
Log SQL queries and see if there’s an index missing?
Have you looked into new oracle indexes for this? We found with rt 3.2.2
it took a lot of tweaking the oracle setup to get fast responses on a
large dataset. We aren’t running 3.4 yet, so can’t actually help you
with it, but that is where I would look first, given that this
apparently works fast on other databases.
What I’d like to see is the drop-down list executing quickly - we have
3.1.14 running (with mysql) with very fast response on the search
page.
3.4.1 against the same data (with Oracle) is considerably slower. I’ve
tried to dig into the code to see what might be causing the slowdown
but
I work at AOL. In 2003, we hired someone (you? it was before I worked
here) from BestPractical to write an add-on for us to integrate RT with
our ChangeManagement tool. It no longer works since our last RT upgrade.
We’re running 3.2.1 now. The tool is in rt/local and it seems like it
isnt even being parsed. Nothing in the error logs, we havent modified
the add-on, and reading its code I dont see anything in it that looks
incompatible with the 3.2.1 API. Attached is the code.
If you’ve got any ideas how to start debugging it… I dont know where
to look even. The “Create CM ticket” link doesnt show up, nothing
appears in the Apache or RT logs… far as I can tell it isnt even
seeing the package.
aolcm-rt.tgz (3.27 KB)