Alternative GUIs for RT?

Vegard_Vesterheim · March 10, 2016, 1:36pm

Some of our users find the RT web gui complex, and also ineffective for
some use-cases. I have been tasked to investigate alternative GUIs
for RT.

The “criticism” relates to the fact that some fields are irrelevant for
some users and should be possible to suppress, and also that the default
ticket display does not allow editing the fields directly. We are
considering creating a new ticket display page which combines the
contents from Basics (Ticket/Modify.html) and History
(Ticket/History.html). This is fairly easy to implement, I guess. Maybe
one could even add a user preference for default ticket display page.

BTW, I am aware of the Jumbo option, and I also know that the latest
version (4.4) can suppress display of unused fields. The mobile UI is
also a possible solution to the complexity concern.

My questions to the list, however, are of a more general nature:

Has anyone considered/implemented/used any alternative GUIs for
manipulating RT tickets?

Vegard V -

akos.torok · March 31, 2016, 3:44pm

Hi Vegard,

We had a plan for a similar goal:
http://lists.bestpractical.com/pipermail/rt-users/2014-March/083068.html

We had and have not enough knowledge to use the new REST interface, so we
couldn’t reach the original goal, but we made a lot of small ajax
implementations:

we have a Results.html with all the fields is editable in the ticket
list, so the user could modify all the data (the columns) without
clicking-getting-diving into the ticket, and diving deeper into the
particular sub-page or jumbo (basics, dates, etc).

a TicketSimple.html, just the necessary data
we’ve changed the Ticket.html header, almost every field (custum and
default) field is ajax editable, no need to move to jumbo or so. Like this:

These are running on RT3.8, some of them on 4.2, we don’t know yet how
those work on 4.4.

We don’t know if our coding style and quality is okay for RT or not, and we
are not familiar how to share this plugins on github or so. So we use these
in house, but we could give you access to our test system, you can try it,
and if you find useful we could send you the code for 3.8 (and the 4.2 as
well but it is not in everyday use).

Bests,

ÁkosOn Thu, Mar 10, 2016 at 2:36 PM, Vegard Vesterheim < vegard.vesterheim@uninett.no> wrote:

Some of our users find the RT web gui complex, and also ineffective for
some use-cases. I have been tasked to investigate alternative GUIs
for RT.

The “criticism” relates to the fact that some fields are irrelevant for
some users and should be possible to suppress, and also that the default
ticket display does not allow editing the fields directly. We are
considering creating a new ticket display page which combines the
contents from Basics (Ticket/Modify.html) and History
(Ticket/History.html). This is fairly easy to implement, I guess. Maybe
one could even add a user preference for default ticket display page.

BTW, I am aware of the Jumbo option, and I also know that the latest
version (4.4) can suppress display of unused fields. The mobile UI is
also a possible solution to the complexity concern.

My questions to the list, however, are of a more general nature:

Has anyone considered/implemented/used any alternative GUIs for
manipulating RT tickets?

–

Vegard V -

RT 4.4 and RTIR Training Sessions (
http://bestpractical.com/services/training.html)

Hamburg Germany - March 14 & 15, 2016

Washington DC - May 23 & 24, 2016

Gary_Greene1 · March 31, 2016, 6:42pm

Wow! This is nice looking and much more functional for average users. Is this still based off RT3 code, or have you based it off the 4.x series? Also, are there any plans to make your changes available for public consumption?

Gary L. Greene, Jr.
Sr. Systems Administrator
IT Operations
Minerva Networks, Inc.
Cell: +1 (650) 704-6633> On Mar 31, 2016, at 8:44 AM, akos.torok@docca.hu wrote:

Hi Vegard,

We had a plan for a similar goal: [rt-users] New UX for RT: REST 2.0, json, and AngularJS vs Backbone.js http://lists.bestpractical.com/pipermail/rt-users/2014-March/083068.html

We had and have not enough knowledge to use the new REST interface, so we couldn’t reach the original goal, but we made a lot of small ajax implementations:

we have a Results.html with all the fields is editable in the ticket list, so the user could modify all the data (the columns) without clicking-getting-diving into the ticket, and diving deeper into the particular sub-page or jumbo (basics, dates, etc).

a TicketSimple.html, just the necessary data

we’ve changed the Ticket.html header, almost every field (custum and default) field is ajax editable, no need to move to jumbo or so. Like this:

These are running on RT3.8, some of them on 4.2, we don’t know yet how those work on 4.4.

We don’t know if our coding style and quality is okay for RT or not, and we are not familiar how to share this plugins on github or so. So we use these in house, but we could give you access to our test system, you can try it, and if you find useful we could send you the code for 3.8 (and the 4.2 as well but it is not in everyday use).

Bests,

Ákos

On Thu, Mar 10, 2016 at 2:36 PM, Vegard Vesterheim <vegard.vesterheim@uninett.no mailto:vegard.vesterheim@uninett.no> wrote:
Some of our users find the RT web gui complex, and also ineffective for
some use-cases. I have been tasked to investigate alternative GUIs
for RT.

The “criticism” relates to the fact that some fields are irrelevant for
some users and should be possible to suppress, and also that the default
ticket display does not allow editing the fields directly. We are
considering creating a new ticket display page which combines the
contents from Basics (Ticket/Modify.html) and History
(Ticket/History.html). This is fairly easy to implement, I guess. Maybe
one could even add a user preference for default ticket display page.

BTW, I am aware of the Jumbo option, and I also know that the latest
version (4.4) can suppress display of unused fields. The mobile UI is
also a possible solution to the complexity concern.

My questions to the list, however, are of a more general nature:

Has anyone considered/implemented/used any alternative GUIs for
manipulating RT tickets?

–

Vegard V -

RT 4.4 and RTIR Training Sessions (http://bestpractical.com/services/training.html http://bestpractical.com/services/training.html)

Hamburg Germany - March 14 & 15, 2016

Washington DC - May 23 & 24, 2016

RT 4.4 and RTIR Training Sessions https://bestpractical.com/training

Washington DC - May 23 & 24, 2016

signature.asc (842 Bytes)

Andrew_Ruthven · March 31, 2016, 9:49pm

Hi Vegard,On Thu, 2016-03-10 at 14:36 +0100, Vegard Vesterheim wrote:

My questions to the list, however, are of a more general nature:

Has anyone considered/implemented/used any alternative GUIs for
manipulating RT tickets?

At my employer - Catalyst IT [0] - we have a public cloud offering
using OpenStack. We’ve added a panel to the OpenStack web management
interface (called Horizon) for creating, viewing and manipulating RT
tickets. It is pretty basic, but provides a much simpler interface for
our customers.

I can provide screenshots, and I expect the code if anyone is
interested.

Cheers,
Andrew

[0] http://catalyst.net.nz

Andrew Ruthven, Wellington, New Zealand
andrew@etc.gen.nz | linux.conf.au 2016
New Zealand’s only Cloud: | LCA By the Bay, Geelong, AU
https://catalyst.net.nz/cloud | http://lca2016.linux.org.au

Vegard_Vesterheim · April 1, 2016, 6:01am

We don’t know if our coding style and quality is okay for RT or not, and we
are not familiar how to share this plugins on github or so. So we use these
in house, but we could give you access to our test system, you can try it,
and if you find useful we could send you the code for 3.8 (and the 4.2 as
well but it is not in everyday use).

This looks promising, with funtionality along the same lines that we
have been contemplating. We would be very interested in having a look at
the code, and also possibly finding a way to continue
sharing/co-developing.this further. Please consider putting this on
Github or a similar hosting service.

Vegard V -

akos.torok · April 4, 2016, 9:57am

Hi Gary, Vegard, Emmanuel,

We are happy that you find these things interesting. Telling the truth we
wanted to make these functions public, but don’t know the proper way.

But now! We are creating one or two plugin of these functions in few weeks
(we are in middle of work, that’s why it take so long), and we would upload
it somewhere to you to download.

Vegard, we would be happy if you upload that to github or so, since we are
not git masters.

Gary, we have stable version for 3.8., but if we have any useful version
for 4.x, I would ask for our programmers to provide those 4.x code as well,
and I would upload those if there is any.

Hi Emmanuel,
I’ve just sent you the password, your username is d2. If you have any
questions, just let me know!

Bests,

ÁkosOn Fri, Apr 1, 2016 at 8:01 AM, Vegard Vesterheim < vegard.vesterheim@uninett.no> wrote:

On Thu, 31 Mar 2016 17:44:55 +0200 akos.torok@docca.hu wrote:

We don’t know if our coding style and quality is okay for RT or not, and
we
are not familiar how to share this plugins on github or so. So we use
these
in house, but we could give you access to our test system, you can try
it,
and if you find useful we could send you the code for 3.8 (and the 4.2 as
well but it is not in everyday use).

This looks promising, with funtionality along the same lines that we
have been contemplating. We would be very interested in having a look at
the code, and also possibly finding a way to continue
sharing/co-developing.this further. Please consider putting this on
Github or a similar hosting service.

Vegard V -

akos.torok · April 14, 2016, 2:05pm

Hi All,

This is the plugin we made: GitHub - docca/rt_cf_ajax

This is against 3.8, so we hope someone would modify the code for 4.x

Bests,

AkosOn Mon, Apr 4, 2016 at 11:57 AM, akos.torok@docca.hu wrote:

Hi Gary, Vegard, Emmanuel,

We are happy that you find these things interesting. Telling the truth we
wanted to make these functions public, but don’t know the proper way.

But now! We are creating one or two plugin of these functions in few weeks
(we are in middle of work, that’s why it take so long), and we would upload
it somewhere to you to download.

Vegard, we would be happy if you upload that to github or so, since we are
not git masters.

Gary, we have stable version for 3.8., but if we have any useful version
for 4.x, I would ask for our programmers to provide those 4.x code as well,
and I would upload those if there is any.

Hi Emmanuel,
I’ve just sent you the password, your username is d2. If you have any
questions, just let me know!

Bests,

Ákos

On Fri, Apr 1, 2016 at 8:01 AM, Vegard Vesterheim < vegard.vesterheim@uninett.no> wrote:

On Thu, 31 Mar 2016 17:44:55 +0200 akos.torok@docca.hu wrote:

We don’t know if our coding style and quality is okay for RT or not,
and we
are not familiar how to share this plugins on github or so. So we use
these
in house, but we could give you access to our test system, you can try
it,
and if you find useful we could send you the code for 3.8 (and the 4.2
as
well but it is not in everyday use).

This looks promising, with funtionality along the same lines that we
have been contemplating. We would be very interested in having a look at
the code, and also possibly finding a way to continue
sharing/co-developing.this further. Please consider putting this on
Github or a similar hosting service.

Vegard V -

Vegard_Vesterheim · June 1, 2016, 9:53am

Some of our users find the RT web gui complex, and also ineffective for
some use-cases. I have been tasked to investigate alternative GUIs
for RT.

The “criticism” relates to the fact that some fields are irrelevant for
some users and should be possible to suppress, and also that the default
ticket display does not allow editing the fields directly. We are
considering creating a new ticket display page which combines the
contents from Basics (Ticket/Modify.html) and History
(Ticket/History.html). This is fairly easy to implement, I guess.

We have now implemented a variant of the Jumbo edit page, calling it
./local/html/Ticket/Edit.html. The idea is to allow this page to be used
as the default ticket display page (instead of Ticket/Display.html).

The user can now edit the ticket directly, having access to the ticket
history in the same page. We need to test this functionality a bit more,
but I wonder if something like this could be considered for inclusion
into RT.

Maybe one could even add a user preference for default ticket display
page.

I tried to register a new User Custom Field, naming the Field
‘PreferEditDisplay’, and allowing two values for the field: ‘Edit’ or
‘Display’. I have registered the value ‘Edit’ for a specific user for
this Custom Field, but I am not able to extract the value
programmatically. I expected the following code to work, but I get no
values back.

my $UserObj = RT::User->new( $session{‘CurrentUser’} );
my $cf_values = $UserObj->CustomFieldValues(‘PreferEditDisplay’);

I tried to enable DBI tracing, expecting to observe some relevant
SELECT-statements from the objectcustomfieldvalues table, but there are
none.

rt4=> select content, disabled from objectcustomfieldvalues where customfield=(select id from customfields where name=‘PreferEditDisplay’);
content | disabled
Edit | 1
Display | 1
Edit | 0

Any hints on how to extract custom field values for a specific custom
field, and a specific User object?

Vegard V -

Emmanuel_Lacour · June 1, 2016, 10:01am

Le 01/06/2016 11:53, Vegard Vesterheim a ï¿½crit :

I tried to register a new User Custom Field, naming the Field
‘PreferEditDisplay’, and allowing two values for the field: ‘Edit’ or
‘Display’. I have registered the value ‘Edit’ for a specific user for
this Custom Field, but I am not able to extract the value
programmatically. I expected the following code to work, but I get no
values back.

my $UserObj = RT::User->new( $session{‘CurrentUser’} );
my $cf_values = $UserObj->CustomFieldValues(‘PreferEditDisplay’);

You just wan’t:

my $cf_value = $UserObj->FirstCustomFieldValue(‘PreferEditDisplay’);

I think.

Vegard_Vesterheim · June 1, 2016, 11:13am

I tried to register a new User Custom Field, naming the Field
‘PreferEditDisplay’, and allowing two values for the field: ‘Edit’ or
‘Display’. I have registered the value ‘Edit’ for a specific user for
this Custom Field, but I am not able to extract the value
programmatically. I expected the following code to work, but I get no
values back.

my $UserObj = RT::User->new( $session{‘CurrentUser’} );
my $cf_values = $UserObj->CustomFieldValues(‘PreferEditDisplay’);

You just wan’t:

my $cf_value = $UserObj->FirstCustomFieldValue(‘PreferEditDisplay’);

I think.

Yes, but I had tried that as well, same result.

I found a solution, I think the problem was related to loading the
correct User Object.

The following works:

my $UserObj = $session{‘CurrentUser’}->UserObj;
my $cf_value = $UserObj->FirstCustomFieldValue(‘PreferEditDisplay’);

I would have thought that
RT::User->new($session{‘CurrentUser’})
and
$session{‘CurrentUser’}->UserObj

would be equivalent, but apparently not.

Thanks for the hint.

Vegard V -

Emmanuel_Lacour · June 1, 2016, 12:39pm

I found a solution, I think the problem was related to loading the
correct User Object.

indeed, I misread you’re code

The following works:

my $UserObj = $session{‘CurrentUser’}->UserObj;
my $cf_value = $UserObj->FirstCustomFieldValue(‘PreferEditDisplay’);

I would have thought that
RT::User->new($session{‘CurrentUser’})
and
$session{‘CurrentUser’}->UserObj

would be equivalent, but apparently not.

no, either:

my $UserObj = RT::User->new($session{‘CurrentUser’});
$UserObj->Load(a user name);

or in your case, just $session{‘CurrentUser’}->UserObj

Thanks for the hint.

you’re welcome

Easter-eggs Spécialiste GNU/Linux
44-46 rue de l’Ouest - 75014 Paris - France - Métro Gaité
Phone: +33 (0) 1 43 35 00 37 - Fax: +33 (0) 1 43 35 00 76
mailto:elacour@easter-eggs.com - http://www.easter-eggs.com

Loos_Christian · June 1, 2016, 1:17pm

I tried to register a new User Custom Field, naming the Field
‘PreferEditDisplay’, and allowing two values for the field: ‘Edit’ or
‘Display’. I have registered the value ‘Edit’ for a specific user for
this Custom Field, but I am not able to extract the value
programmatically. I expected the following code to work, but I get no
values back.

my $UserObj = RT::User->new( $session{‘CurrentUser’} );
my $cf_values = $UserObj->CustomFieldValues(‘PreferEditDisplay’);

You can easily add custom user preferences.
Have a look here:

github.com

tbrumm/RT-Extension-SideBySideView/blob/master/lib/RT/Extension/SideBySideView.pm#L9-L17


      
          $RT::Config::META{'SideBySideView'} = {
              Section         => 'Ticket display',
              Overridable     => 1,
              Widget          => '/Widgets/Form/Boolean',
              WidgetArguments => {
                  Description => 'Display History besides Metadata', # loc
                  Hints       => '(' . __PACKAGE__ . ')',
              },
          };

This new preference is used here:

github.com

tbrumm/RT-Extension-SideBySideView/blob/master/html/Callbacks/SideBySideView/Ticket/Display.html/BeforeShowSummary#L15


      
                  jQuery("div.card-body > div.ticket-summary > div").wrapAll("<div class='boxcontainer col'></div>");
                  jQuery("div#body > div.summary").css({float: "left", width: "30%"});
                  jQuery("div#body > div.summary > div.fullwidth > div.titlebox").css({"margin-top": "0", "margin-right": "20px"});
          % } else {
                  jQuery("table.ticket-summary td.boxcontainer > div:first-child").unwrap();
                  jQuery("#body > div.summary, #body > div.summary ~ div").wrapAll("<table width='100%'><tr></tr></table>");
                  jQuery("#body > div.summary ~ div").wrapAll("<td valign='top' class='boxcontainer'></td>");
                  jQuery("div.summary").wrap("<td valign='top' class='boxcontainer' style='width: 30%;'></td>");
          % }
              });
          </script>
          <%init>
          return unless RT->Config->Get( 'SideBySideView', $session{'CurrentUser'} );
          </%init>

Chris

Vegard_Vesterheim · June 7, 2016, 7:29am

Am 01.06.2016 um 11:53 schrieb Vegard Vesterheim:

I tried to register a new User Custom Field, naming the Field
‘PreferEditDisplay’, and allowing two values for the field: ‘Edit’ or
‘Display’. I have registered the value ‘Edit’ for a specific user for
this Custom Field, but I am not able to extract the value
programmatically. I expected the following code to work, but I get no
values back.

my $UserObj = RT::User->new( $session{‘CurrentUser’} );
my $cf_values = $UserObj->CustomFieldValues(‘PreferEditDisplay’);

You can easily add custom user preferences.
Have a look here:
RT-Extension-SideBySideView/lib/RT/Extension/SideBySideView.pm at master · tbrumm/RT-Extension-SideBySideView · GitHub

Ah, this is much better than using a User Custom Field, since this is a
custom user preference after all. Thank you.

This new preference is used here:
RT-Extension-SideBySideView/html/Callbacks/SideBySideView/Ticket/Display.html/BeforeShowSummary at master · tbrumm/RT-Extension-SideBySideView · GitHub

I ended up using the EachRow callback from CollectionList. I sneakingly
alter the link for the Ticket landing page (from Display.html to our
local Edit.html) according to the user preference.

The callback hooks in RT is very useful for doing these sorts of
hacks;-)

Vegard V -