Select Page

NETWAYS Blog

Request Tracker: Highlight tickets based on due dates

by | Jan 16, 2019 |

A while ago we’ve announced a new extension for Request Tracker which allows to highlight tickets in search results even better.

Next to “last updated by” and custom field conditions, we’ve now added a requirement from production:

  • light red coloring for tickets with a due date in 3 days
  • dark red coloring for everything where the due date already passed

When there’s a ticket which matches one of the other conditions, due date wins over “last updated by” which itself wins over custom field conditions.

v2.0.0 is available on GitHub. Consider asking our sales engineers when building a new RT instance in NWS 🙂

New Request Tracker Extensions: Search Result Highlights, Quick Assign & User Overview

by | Dec 13, 2018 | ,

We use Request Tracker on a daily basis, and have written many extensions for our own workflows and visualizations. Lately we’ve been helping a customer to migrate from OTRS to RT running in NWS, and learned about new ways to improve our workflows.

Highlight Search Results on Conditions

When you own a ticket, but someone else updated the ticket with a comment/reply, you want to immediately see this. Our extension makes this possible with either a background color or an additional icon (or both).
You can also limit this to replies/comments from customers, where the last update wasn’t performed by users in a specific group. This allows to immediately see support or sales tickets which need to be worked on in the dashboards.
Another use case is to highlight search result rows when a custom field matches a specified value. If you’re setting tickets for example, you can visually see the difference between a “bought ticket” and “paid ticket” state.
While developing the extension, I’ve also fixed an upstream RT bug which has been merged for future releases. There’s even more possibilities, as we’ve recognised that one of the BestPractical/RT developers forked our extension already 🙂

Quick Assign People to Tickets

By default, one needs to edit the “People” tab to assign a ticket to a privileged user, or modify adminCC and the requestor. This takes far too long and as such, our own NETWAYS extension improved this with drop-downs and action buttons. We have now open-sourced this feature set into a new extension on GitHub: rt-extension-quickassign.

 

Show Ticket Count per User and Status

This extension was released a while ago, and we’ve fixed a bug with empty sets in there. In addition to that, we’ve added a new configuration option which allows to list specific groups and their members, and not only privileged users. This comes in handy to only show the NETWAYS members but not any root or meta accounts. Read more on GitHub.

Do you need more customizations for Request Tracker, or want to run RT in a managed cloud environment? Just get in touch 🙂

RT Extensions Made Easy

by | Mar 22, 2018 | ,

Heute geht es darum, wie man auf einfache Art und Weise Erweiterungen für Request Tracker vorbereitet. Einen kleinen Ausblick darauf wie man sie dann auch schreibt, gibt es am Ende auch, aber mehr würde den Rahmen dieses Posts sprengen.
Bevor wir beginnen, müssen jedoch erst einige Vorbereitungen erledigt werden:
# cpanm Module::Install::RTx Dist::Zilla::MintingProfile::RTx
Dies installiert einige Werkzeuge die wir für die folgenden Beispiele benötigen.
Außerdem bietet es sich an, ein paar grundlegende Informationen über die eigene Person zu konfigurieren. Das erspart uns später einige Angaben:
$ dzil setup

Wer sich fragt was man alles mögliche an Lizenzen angeben kann, darf hier einen Blick riskieren.
Schon kann es losgehen. Zuerst erstellen wir mit dem sogenannten “profile provider” RTx ein blankes Skelett.
Dies erstellt dort wo wir uns gerade befinden ein neues Verzeichnis mit dem Namen “RT-Extension-Netways”:
$ dzil new -P RTx RT-Extension-Netways

Die darin enthaltene Datei “Netways.pm” nun öffnen und entsprechend anpassen bzw. erweitern. Darunter fallen i.d.R. der Name, die Beschreibung, die RT Versions-Voraussetzungen und die Autoren Angabe. Der Rest sollte bereits größtenteils vorausgefüllt sein, wie schon zuvor erwähnt.
Außerdem ist es ratsam sich die Datei “Makefile.PL” einmal genauer anzusehen. Denn dort sind ebenfalls einige wichtige Angaben zu finden über deren Korrektheit man sich vergewissern sollte.
Hat man dies getan, kann man bereits mit der eigentlichen Entwicklung der Erweiterung beginnen.
Hierzu sei jedem die offizielle Dokumentation von Best Practical und HTML::Mason ans Herz gelegt.
Ist man letztendlich fertig mit der Entwicklung oder möchte schon einmal testen was man da tolles fabriziert hat, ist es an der Zeit die Verteilung seiner neuen Erweiterung vorzubereiten:
$ perl Makefile.PL

Da dies die erste Ausführung von “Makefile.PL” war, wurden einige für die Installation notwendige Bibliotheken in die Struktur integriert. Diese sind notwendig, damit Nutzer die Erweiterung zumindest installieren können, ohne zusätzlich notwendige Abhängigkeiten.
Außerdem wurden einige zusätzliche Dateien und Verzeichnisse angelegt. Diese jedoch sind nur ein Nebenprodukt und nicht notwendig für die Verteilung. (Darunter das “Makefile” und die “MYMETA.*” Dateien.) Was alles genau nicht notwendig ist, kann in der Datei “gitignore” nachgelesen werden. (Wer sowieso mit Git arbeitet, kann diese Datei auch zu “.gitignore” umbenennen.)
Nun folgt man nur noch den üblichen Schritten und schon kann die Erweiterung konfiguriert und genutzt/getestet werden:
$ make
# make install

Johannes Meyer
Johannes Meyer
Lead Developer
Johannes ist seit 2011 bei uns und inzwischen, seit er 2014 die Ausbildung abgeschlossen hat, als Lead Developer für Icinga Web 2, Icinga DB Web sowie alle möglichen anderen Module und Bibliotheken im Web Bereich zuständig. Arbeitet er gerade mal nicht, macht er es sich bei schlechtem Wetter am liebsten zum zocken oder Filme/Serien schauen auf dem Sofa gemütlich. Passt das Wetter, geht's auch mal auf eines seiner Zweiräder. Motorisiert oder nicht.
Read more from Johannes and meet the Team

NETWAYS Web Services: Connect to your own Domain!

by | Nov 29, 2017 | , , , , , , , , ,

Our team has continued to improve the NETWAYS Web Services products for providing more comfort to our customers. Now any app can be run under its own Domain Name in combination with its own SSL certificate. This option is available for the following products:

The implementation within the product is quite simple. After your app has been created successfully, you will find a new webform in your app’s Access tab. Here is an example of a Request Tracker app:

As the webform shows, customers simply have to enter a registered Domain Name and their SSL Certificate as well as their SSL Key. The implementation in the app will be done by our NWS platform fully automated. Customers only need to take care about the quality and correctness of the certificate and to make sure they enter the DNS record correctly on their Domain Name Server. The IP address needed will be indicated underneath the webform in the information section. Furthermore, it is still possible to set an additional CName for your app. This means that your customized Domain Name and the CName can be used in parallel. Furthermore, the platform generated standard URL will stay valid and customers can always go back to the initial settings by removing their entries from the webform.
After clicking the save button, the app will be restarted and all changes will be taken into production immediately.
The bonus of this option is clear: Anybody working with your apps will be glad to use easy to read and memorize URLs. Furthermore, company identity and culture is even more important today than ever. So why not also provide your SuiteCRM, Rocket.Chat or Nextcloud with a well branded URL?
More information can be found on our NWS homepage, in any of our product sections or by contacting us via the NWS livechat.
Important note: All NWS products are up for a 30 day free trial!

NETWAYS Web Services: Request Tracker

by | Sep 6, 2017 | , , , , ,

Unsere NWS-Produktfamilie ist um ein weiteres Mitglied gewachsen: Den BestPractical Request Tracker. Dies wird vor allem Kunden freuen, die zwar ein stabiles und zuverlässiges Ticketsystem nutzen möchten, sich aber nicht um die Bereitstellung von Ressourcen, die Installation sowie die Wartung kümmern möchten – denn all dies wird von unserer NETWAYS Web Services Plattform übernommen. Der Kunde selbst muss sich nur um eine Hand voll Voreinstellungen kümmern, die jedoch direkt über Webformulare an die App übergeben werden.

Diese Voreinstellungen umfassen folgende Aspekte, die der Kunde bereitstellen muss:

  • ein IMAP oder POP3 Postfach, von dem der Request Tracker Kundenmails abholt und daraus ein Ticket generiert. Dies stellt vor allem sicher, dass bestehende Mail-Adressen weiter genutzt werden können.
  • einen SMTP-Server, der den Versand der Mails aus dem Request Tracker steuert.

Des Weiteren bietet unsere App viele Möglichkeiten, den Request Tracker nach Belieben anzupassen. Kunden können nicht nur den Namen Ihres Request Trackers und Ihrer Organisation festlegen, sondern auch eine Zeitzone und eine eigene Absender-Mail-Adresse eintragen:

Auch innerhalb der App kann der Request Tracker hervorragend an Ihr Unternehmen angepasst werden. Es können nicht nur im administrativen Bereich User-Gruppen und Ticket-Queues erstellt werden, sondern auch das Erscheinungsbild des Tools individualisiert werden.
Wichtiger Hinweis: Alle Angebote bei den NETWAYS Web Services können Sie 30 Tage kostenfrei testen!

Trainings

Web Services

Events