Customizing the RT log-in page

Hello everyone,

I want to customize the front page which one gets as soon as I log-in
into RT.

Our company has a number of queues, and the front page contains a lot of
information that is useless to our group members.

What I want is that when I log in, RT should contain a list of my open
tickets sorted in order of date, and nothing else.

Is it possible to do this?

Thanks,

  • Onkar

Hello everyone,

I’m trying to access “Attachments” attached to a ticket from a scrip and I
can’t figure out how to do this…
Can someone give me some pointers or sample code to do this ?

Thank you!

Romain DEGEZ, IT Manager

Smartjog S.A. - http://www.smartjog.com
16 Place de la République, 75010 Paris, FRANCE
Phone : +33.1.49.96.63.19
Fax : +33.1.49.96.64.05
Cell : +33.6.84.24.65.21

OK … We are running RT 3.4.5 and I’m having trouble trying to achieve
something that we want to do. I think I’m close but I just need a little
help to get over the edge.

Basically, for specific queues, we have a custom field that contains a list
of users. The list of users is a list of people that can approve
tickets. When a user is selected an approval ticket is generated for the
specified user. If no one is selected (no value) then it creates the
ticket normally. This part works fine.

We realized that if someone might create the ticket initially not thinking
that it needs to be approved and then discover that it approval is
required. We wanted to make it so a user could go back and select an
approver and generate the approval request as it would if it were done at
the original creation of the ticket.

What I was thinking I could do is compare the old value of the custom field
with the current value of the custom field and if they had changed I could
return 1 and run the approval template. If this can be done, I would also
want to check to see if the new value was “no value” and if it were then I
would return 0.

I have searched the archives and can come up with stuff that is close but
nothing that actually does a check on the old value of a custom field
within the scrip. Part of the problem is that I’m not entirely sure what
the proper syntax of referring to the fields and their values. So if there
is some place that can give me a break down of how to do this that would be
great.

Here is the contents of the User Defined Condition as it works on the
creation of a ticket:

if (($self->TransactionObj->Type eq “Create”) and
($self->TicketObj->FirstCustomFieldValue(‘Approval required by:’) =~ /\w/)) {
return 1;
}
return 0;

Here is the contents of the template that is called by the above scrip:

===Create-Ticket: manager-approval
Queue: ___Approvals
Type: approval
Owner: { $Tickets{‘TOP’}->FirstCustomFieldValue(‘Approval required
by:’) }
Depended-On-By: { $Tickets{‘TOP’}->Id() }
RefersTo: { $Tickets{‘TOP’}->Id() }
Content: Please review and approve this request.
ENDOFCONTENT

I was attempting to add further checks in the scrip that basically look to
see if the transaction type is not equal to “Create” . If that was the
case then I would look at the custom field value (‘Approval required by:’)
and see if it had changed.

I sure hope someone has something I can run with. I don’t even have to
have the complete answer. Just point me in the right direction. Any help
would be greatly appreciated.

Thanks
John

John A. Walker wrote:

OK … We are running RT 3.4.5 and I’m having trouble trying to
achieve something that we want to do. I think I’m close but I just
need a little help to get over the edge.

Basically, for specific queues, we have a custom field that contains a
list of users. The list of users is a list of people that can approve
tickets. When a user is selected an approval ticket is generated for
the specified user. If no one is selected (no value) then it creates
the ticket normally. This part works fine.

We realized that if someone might create the ticket initially not
thinking that it needs to be approved and then discover that it
approval is required. We wanted to make it so a user could go back
and select an approver and generate the approval request as it would
if it were done at the original creation of the ticket.

What I was thinking I could do is compare the old value of the custom
field with the current value of the custom field and if they had
changed I could return 1 and run the approval template. If this can
be done, I would also want to check to see if the new value was “no
value” and if it were then I would return 0.

I have searched the archives and can come up with stuff that is close
but nothing that actually does a check on the old value of a custom
field within the scrip. Part of the problem is that I’m not entirely
sure what the proper syntax of referring to the fields and their
values. So if there is some place that can give me a break down of
how to do this that would be great.

Here is the contents of the User Defined Condition as it works on the
creation of a ticket:

if (($self->TransactionObj->Type eq “Create”) and
($self->TicketObj->FirstCustomFieldValue(‘Approval required by:’) =~
/\w/)) {
return 1;
}
return 0;

Here is the contents of the template that is called by the above scrip:

===Create-Ticket: manager-approval
Subject: Approval of { $Tickets{‘TOP’}->Subject() }
Queue: ___Approvals
Type: approval
Owner: { $Tickets{‘TOP’}->FirstCustomFieldValue(‘Approval
required by:’) }
Depended-On-By: { $Tickets{‘TOP’}->Id() }
RefersTo: { $Tickets{‘TOP’}->Id() }
Content: Please review and approve this request.
ENDOFCONTENT

I was attempting to add further checks in the scrip that basically
look to see if the transaction type is not equal to “Create” . If
that was the case then I would look at the custom field value
(‘Approval required by:’) and see if it had changed.

I sure hope someone has something I can run with. I don’t even have
to have the complete answer. Just point me in the right direction.
Any help would be greatly appreciated.

Thanks
John


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

We’re hiring! Come hack Perl for Best Practical:
Careers — Best Practical Solutions

John,

You seem to have gone to a lot of work to get some form of approvals 

going with certain people being allowed to do that, but it looks to me
like you went the long way around the barn. Without ANY PERL scrips or
anything, I have a Queue set aside for approvals, it receives requests
by any group (of users) allowed or the group that “supports”
(Approvals-Support) with the right privileges can create, own, whatever
the needs are to/for a request. Then when approved, they (the approvers)
merely change the owner to “nobody” and change the Queue to where the
requests belongs. Everything is in history under the same ticket number
(great for auditors). By creating all this code, you may have created a
house of cards that will be difficult to maintain, whereas by using RT
as-is, we have much less maintenance to perform. Think about it. I
really have no advice to give about all the extra code.

Kenn

Kenn - Thanks for taking the time to respond. It is greatly
appreciated. Let me explain a little more and then you can let me know if
what you’re doing would still apply. In essence we were wanting the user,
as they create the ticket, to be able to select the person that needed to
approve the ticket. We did this by creating a custom field with the list
of users that can approve a ticket. Once a user creating the ticket
selected a person to approve, the ticket create process would also create
the approval request for the person selected as the approver.

I can’t tell for sure but I’m thinking that you have a certain group of
users that are allowed to look in the approval queue and users simply
submit approvals into this queue? If I’ve misunderstood how your situation
works let me know. Perhaps what you are doing would work for our
situation. The key to our situation is the need to have a ticket creator
be able to select the user they want to approve a ticket. If that can be
done with your method and you have the time please give me a little more
detail.

Thanks again.

John

John A. Walker wrote:

Kenn - Thanks for taking the time to respond. It is greatly
appreciated. Let me explain a little more and then you can let me
know if what you’re doing would still apply. In essence we were
wanting the user, as they create the ticket, to be able to select the
person that needed to approve the ticket. We did this by creating a
custom field with the list of users that can approve a ticket. Once
a user creating the ticket selected a person to approve, the ticket
create process would also create the approval request for the person
selected as the approver.

I can’t tell for sure but I’m thinking that you have a certain group
of users that are allowed to look in the approval queue and users
simply submit approvals into this queue? If I’ve misunderstood how
your situation works let me know. Perhaps what you are doing would
work for our situation. The key to our situation is the need to have
a ticket creator be able to select the user they want to approve a
ticket. If that can be done with your method and you have the time
please give me a little more detail.

Thanks again.

John

John,

You seem to have gone to a lot of work to get some form of
approvals going with certain people being allowed to do that, but it
looks to me like you went the long way around the barn. Without ANY
PERL scrips or anything, I have a Queue set aside for approvals, it
receives requests by any group (of users) allowed or the group that
“supports” (Approvals-Support) with the right privileges can create,
own, whatever the needs are to/for a request. Then when approved,
they (the approvers) merely change the owner to “nobody” and change
the Queue to where the requests belongs. Everything is in history
under the same ticket number (great for auditors). By creating all
this code, you may have created a house of cards that will be
difficult to maintain, whereas by using RT as-is, we have much less
maintenance to perform. Think about it. I really have no advice to
give about all the extra code.

Kenn

John,

Yes, you are partially correct. We have a queue whose sole purpose 

is to filter request for several other support queues. We don’t allow
the users (or requestors) to create tickets in the technical support
Queues directly, only to the Approvals Queue. The members of the group
that has been assigned privileges for that Approval Queue (like owners,
create (a sub-ticket) or in some cases, like a training issue or
permissions, they even resolve the ticket and the ticket never goes on
to our technical support Queue) all know what type of tickets to deal
with. The difference from your understanding is we don’t let the
requestor select the person who will approve the ticket. We have a group
of approvers (in a group assigned privileges to the Approval Queue) who
already know what they can work on/approve. If a ticket for Accounts
Payables shows up in the Approvals Queue, a member of our
Approvals-Support Group KNOWS he has been assigned to work with AP so he
will see the ticket when he checks the approvals Queue and TAKE the
ticket, based on what he reads in the subject matter or based on the
requestor name. Now he owns it and researches the problem and either
resolves the problem (training issue or whatever) or he realizes that
this request needs technical support. So he then makes a change to the
STATUS field (we put in a change and added some new statuses like “rq
approvd”, “rejected” (you’re only allowed 10 characters for that
field)), changes the owner to “nobody” (we tried to create a scrip to do
this automatically upon Queue Change and couldn’t get it to work
correctly so we have the approver do it manually right now until we can
get the scrip to work properly), then the approver changes the Queue to
the appropriate Technical Support Queue, in this case the “AP” Queue.
Then the “AP-Support” group or AdminCc of the “AP” Queue sees the ticket
in their Queue and either the AdminCc assigns an owner or one of the
technicians that are members of that support group takes the ticket and
it gets worked on. We like this method better than the built in RT
Approvals work-flow because all the history stays with the original
ticket number (and we have been seeing ALOT of e_mails from users having
difficulty in getting the RT-Approval function to work, plus the
RT-Approvals functon sets up a “hidden” approval queue for “each” Queue
and creates a new ticket when approved and we like the flexibility of
being able to set up a visible Approval Queue that can handle the
requests of many support queues - without being hidden). This is also
perfect for our auditors. They actually smile when they see this history
all on one ticket. We also like this design because it uses the basic RT
functionality without a lot of extra scrips being written (and therefore
maintained). I’ve been in this business (Data Processing, I know - old
term) for over 35 years and if I’ve learned anything, it’s that the less
you complicate something, the easier it is to run, maintain, and debug.
“simpler” is just better, at least for me. Anyway, thats the way we do
it and it’s working just fine. Our users love it because they can still
monitor the progress of their request from waiting for approval to being
moved to a technical Queue for work, to resolution, the Technical
support group assigned to the Queue that handles the work for “AP” like
it because they aren’t bothered by a bunch of requests that are not
technical and can be handled by a Business Analyst, and our Auditors
love it because all the history is there under 1 ticket number.
Anyway, that’s what we have created by design. If this is something
you think will work for you, great. It certainly does for us and as I
said, it’s a lot simpler.

Kenn