Organisations vs individual requestors

Hi,

We’re looking at migrating to RT2 from a never quite finished inhouse
developed “thing”.

One thing that our existing system has is a concept of organisations. We
can easily determine how many tickets an organisation has open (we might
have multiple requestors from the one organisation).

I know that the auto-created users that get made when a new requestor is
seen can have an Organisation specified, and I know you can search for
users based on organisation, but how hard would it be to implement ticket
searching/filtering based on requestor organisation? Possibly this is a
feature request… To be able to view the organisation in the queue, and
to be able to search and filter based on it?

The hierarchy for us is the organisation is the customer, not the
individual requestors.

I figure that we can knock up a custom PHP page to produce a report from
the RT database pretty easily, but it would be good to tie this directly
into RT.

Andrew

hi andrew,

you might want individual queues set up for each organisations, i guess.
this way it’s quite easy to find out how many tickets an organisation has open.

but maybe i got you wrong.

cu
andreas

We’re looking at migrating to RT2 from a never quite finished inhouse
developed “thing”.

If you’ve got enough development to try your own ticket system, making the
following change should be pretty easy:

I know that the auto-created users that get made when a new requestor is
seen can have an Organisation specified, and I know you can search for
users based on organisation, but how hard would it be to implement ticket
searching/filtering based on requestor organisation? Possibly this is a
feature request… To be able to view the organisation in the queue, and
to be able to search and filter based on it?

Adding the view is really easy: merely add the ‘lookup’ to the display of
whatever you want… It’s just another property of Requestor you can
display. See my recent mail about adding to the My* Elements, or add it
to the main listing (I think that’s defined in config.pm)

Search and filter, similarly, it’s mostly a matter of cloning… take a
look for sections in Search and Web.pm using ValueofRequestor, and copy
that I think, then make changes as to what property you are using.

hi andrew,

you might want individual queues set up for each organisations, i guess.
this way it’s quite easy to find out how many tickets an organisation has open.

but maybe i got you wrong.

That doesn’t really scale though, you’d end up with heaps of queues to
watch.

Andrew

We’re looking at migrating to RT2 from a never quite finished inhouse
developed “thing”.

If you’ve got enough development to try your own ticket system, making the
following change should be pretty easy:

How do major code customisations like you’re suggesting carry across
upgrades?

Andrew

We’re looking at migrating to RT2 from a never quite finished inhouse
developed “thing”.

If you’ve got enough development to try your own ticket system, making the
following change should be pretty easy:

How do major code customisations like you’re suggesting carry across
upgrades?

I’d call this a minor customization. I’d suspect about a hour’s worth of
work.

Well, the web front end (ie the display parts) is Mason, and it is built
with a ‘local’ directory for code changes. Worst case, you’d want to diff
and patch new versions, if the new version of a page had something you
need/want/etc

The backend (the perl side), mostly I’m suggesting adding a
subroutine/line to handle the added functionality. Should be pretty safe
for the future.

Then, there is always the best way: code it so that Jesse likes it, and
it’ll find it’s way into the codebase for everyone. :slight_smile:

Seth

Thanks to the people who have replied to my question.

I’ve discovered that it’s quite trivial to add additional columns to the
search page that shows the tickets in a queue.

I’m just not sure on how to put there what I want.

I’ve added an Organisation column, but I don’t know how to display the
Organization field of the requestor user. Is there any documentation on
the objects and their properties? I tried RequestorObj->Organization as a
wild punt, but it didn’t work.

Andrew

I’ve added an Organisation column, but I don’t know how to display the
Organization field of the requestor user. Is there any documentation on
the objects and their properties? I tried RequestorObj->Organization as a
wild punt, but it didn’t work.

Try Ticket->RequestorObj->Organization
that’s the Org of the Requestor of the Ticket

For the Email of the Owner of the Ticket, use
Ticket->OwnerObj->EmailAddress, etc

Transactions and Tickets tend to be the base part of most queries.
(All of the -> stuff is DBI:SearchBuilder, doing a query on the DB)

See

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

The schema describes the objects and properties.

I’ve added an Organisation column, but I don’t know how to display the
Organization field of the requestor user. Is there any documentation on
the objects and their properties? I tried RequestorObj->Organization as a
wild punt, but it didn’t work.

From your ticket object, you can do the following:

my %orgs_seen = ();
my $requestors = $this_ticket->Requestors;
while( my $requestor = $requestors->Next ){
	$orgs_seen{$requestor->OwnerObj->Organization}++;
}

# Then see whats in %orgs_seen for display.

Requestors on a ticket (RT 2.0.x) are ‘watcher’ objects of a particular
type, which are then ‘owned’ by User objects, which has the mispelled
’Organization’ field. A given ticket can have multiple ‘requestors’, so
be sure to take that into account.

Regards,

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B             Operations/Security

I’ve added an Organisation column, but I don’t know how to display the
Organization field of the requestor user. Is there any documentation on
the objects and their properties? I tried RequestorObj->Organization as a
wild punt, but it didn’t work.

Try Ticket->RequestorObj->Organization
that’s the Org of the Requestor of the Ticket

For the Email of the Owner of the Ticket, use
Ticket->OwnerObj->EmailAddress, etc

Transactions and Tickets tend to be the base part of most queries.
(All of the -> stuff is DBI:SearchBuilder, doing a query on the DB)

I tried Ticket->RequestorObj->Organization
and
RequestorObj->Organization

without success.

See

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

The schema describes the objects and properties.

I have read the FAQ. I’ll have a reread, but I didn’t see anything that
mapped the database schema to the objects.

Andrew

I tried Ticket->RequestorObj->Organization
and
RequestorObj->Organization

without success.

It’s CreatorObj->Organization

Andrew

I tried Ticket->RequestorObj->Organization
and
RequestorObj->Organization
without success.

It’s CreatorObj->Organization

Is it always? :wink:

If you’re using $this_ticket->CreatorObj->Organization , you get the
Organization field of the person who created the ticket. For tickets
created via email, this should be the same person as the requestor.

However (and not knowing your workflow), tickets created by say, a
helpdesk person based on a phone call, would inherit (by your method) the
Organization field of the helpdesk person, not the actual requestor.

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B             Operations/Security

Hi,

We’re looking at migrating to RT2 from a never quite finished inhouse
developed “thing”.

One thing that our existing system has is a concept of organisations.
We
can easily determine how many tickets an organisation has open (we
might
have multiple requestors from the one organisation).

I would either give each organisation it’s own queue and whip up some
procmail magic which automatically finds out which organisation a user
belongs to. You give out the genral address, which processes incoming
mail using procmail and sends to the queue specific addresses.

Regards,
Harald Wagener

Harald Wagener * FCB/Wilkens * An der Alster 42 * 20099 Hamburg

It’s CreatorObj->Organization

Is it always? :wink:

If you’re using $this_ticket->CreatorObj->Organization , you get the
Organization field of the person who created the ticket. For tickets
created via email, this should be the same person as the requestor.

However (and not knowing your workflow), tickets created by say, a
helpdesk person based on a phone call, would inherit (by your method) the
Organization field of the helpdesk person, not the actual requestor.

Poo. The workflow I’m envisaging would be tickets get created via email,
or by a helpdesk operator manually entering one. How do I get around the
creator issues with the latter?

Andrew

It’s CreatorObj->Organization

Is it always? :wink:

If you’re using $this_ticket->CreatorObj->Organization , you get the
Organization field of the person who created the ticket. For tickets
created via email, this should be the same person as the requestor.

However (and not knowing your workflow), tickets created by say, a
helpdesk person based on a phone call, would inherit (by your method) the
Organization field of the helpdesk person, not the actual requestor.

Poo. The workflow I’m envisaging would be tickets get created via email,
or by a helpdesk operator manually entering one. How do I get around the
creator issues with the latter?

Bruce, I found this email you helped with that points to the solution
needed:

http://lists.fsck.com/pipermail/rt-devel/2002-May/002239.html
(and the search patch referred there would also help Andrew out I think)

‘Requestors->First->OwnerObj->Organization’

Andrew, put this in into your config.pm:

{ Header => ‘Organization’,
TicketAttribute => ‘Requestors->First->OwnerObj->Organization’,
},

If you have 2 different requestors from different orgs, this won’t work,
but it doesn’t sound like that’s an issue here.

Seth