Forward the $term variable to debian the xshell-way

Xshell is yet another putty-like terminal client for windows that features a couple of nice extensions. See the net for a multitude of alike “top-10 terminal clients for windows” posts. Among the features, Xshell does not only provide a raw terminal pane but also runs a so called local shell that actually embeds remote shells. In other words, initially (standard configuration) you get your xshell window, running the Xshell shell and offering a number of internal commands to act in the realm of Xshell by means of simple keystrokes. If you’re addicted to the keyboard, like me, this is a very pleasent way to go. For example, see the help output, a list of available sessions (connect profiles already configured) and an open to eventually connect to the remote host:

Anything keyed and, by the way, the session name even tab-expanded after a few characters. Cool, right?

Ok, that much for the preface, important to understand what followes next, the forwarding of a dedicated environment setting, namely TERM=xterm-256color with this terminal client (see why e.g.:, see others e.g.:

The point is, based on the local shell, Xshell is able to inject/communicate code the the remote shell in an after-login but pre-(final-)prompt fashion. All you need to do is to code a snippet to call some member functions of the current local shell Screen object. Three language binding are possible so far: js, py and vbs. Examples are given in AppData\Local\NetSarang Computer\6\Xshell\Scripts\ScriptSample, documentation resides as . In order to achive the forward, the following code is sufficient (don’t ask my why a sleep is needed here):

def Main():
	xsh.Screen.Synchronous = True  # True or False
	xsh.Screen.Send("export TERM=xterm-256color\r")

The file location can be configured in the sessions connect profile dialog like so. Done!

After all, the tiled and full screen view modes are also worth a try. Like it.


Install the Oracle OE- and SH-schemata for the OrderEntry- and SalesHistory-benchmarks

# - oe takes intermedia, sh takes partitioning and bitmap-indexes, so ee is a must
# -

# [ $ ~ ]
mkdir sample-schemas ; cd sample-schemas
cp -R db-sample-schemas-* $ORACLE_HOME/demo/schema
cd $ORACLE_HOME/demo/schema
perl -p -i.bak -e 's#__SUB__CWD__#'$(pwd)'#g' *.sql */*.sql */*.dat

# yet install
rlsqlplus system/oracle@my_db_srv
show con_name -- MY_DB_SRV
-- system_password sys_password hr_password oe_password pm_password ix_password sh_password
--   bi_password tablespace_name temp_tablespace_name log_location ez_connect_string
@mksample oracle oracle hr oe pm ix sh bi users temp /u01/app/oracle/product/12.2.0/dbhome_1/demo/schema/log/ my_db_srv

# see the oe/sh log files
less $ORACLE_HOME/demo/schema/log/oe_oc_v3.log
less $ORACLE_HOME/demo/schema/log/sh_v3.log

OTRS Dashboard / Set up an agent statistic element (widget)

OTRS does provide agent statistics to show on the dashboard. However, this settings is not active by default, so you’ll have to enable this feature in Admin->SysConfig under the UseAgentElementInStats identifier first.
Go and search for it, using the upper left input field, as usual, then switch it on.


OTRS Dashboard / Provide bulk update dialog link in ticket details view

Continuing on the last posting, this acticle is about some hack (still in conformity with the underlying OTRS framework) to have the beloved bulk-update dialog link (and functionality) available in the ticket detail view. Why so? Well, to be honest and for the sake of brevity, the bulk-update dialog allows for a multitude of changes applied to a ticket without documenting each and every piece of change with a subject and a body text message. As an example, regard changing the owner and the responsible from within some ticket detail view. It will take two popups and at least four text input fields to be nourished… On the other hand, you may set all this flags like Ticket::Frontend::AgentTicketClose###NoteMandatory to get rid of the notes restraint but that is yet another approach.
Ok, however, the bulk-update dialog, by its nature, is a multi-element (ticket) user interface artefact and in such a way only uplinked on pages with, usually, a couple of checkboxes, e.g. the standard OTRS status view. Since the ticket detail view is a single-element artefact, there is no bulk action element in place, why should it.
So, yet again, we walk the path pioneered by the underlying OTRS framework, documented in OTRS developer book and ConfigReference Ticket (search for Ticket::Frontend::MenuModule) as well as to some extend blogged about by the SectorNord people in [((OTRS)) Community Edition] Displaying and hiding menu entries in the ticket view.
First up, we create another ConfigItem entry in /opt/otrs/Kernel/Config/Files/Ticket-Local.xml file, familiar from the last post. Any already existing ConfigItem entry of type Ticket::Frontend::MenuModule from /opt/otrs/Kernel/Config/Files/Ticket.xml may serve as a template.

Using Ticket::Frontend::MenuModule###470-Junk we take the following adaptions to set up the new Ticket::Frontend::MenuModule###010-Bulk. Please note that the name change also serves as a sorting index of the menu items from left to right. 010-Bulk will therefore immediately follow 000-Back as the second menu item.

    <ConfigItem Name="Ticket::Frontend::MenuModule###470-Junk" Required="0" Valid="0">
        <Description Translatable="1">Shows a link to set a ticket as junk in the ticket zoom view of the agent interface. Additional access control to show or not show this link can be done by using Key "Group" and Content like "rw:group1;move_into:group2". To cluster menu items use for Key "ClusterName" and for the Content any name you want to see in the UI. Use "ClusterPriority" to configure the order of a certain cluster within the toolbar.</Description>
                <Item Key="Module">Kernel::Output::HTML::TicketMenu::Generic</Item>
                <Item Key="Name" Translatable="1">Spam</Item>
                <Item Key="Action">AgentTicketMove</Item>
                <Item Key="Description" Translatable="1">Mark this ticket as junk!</Item>
                <Item Key="Link">Action=AgentTicketMove;TicketID=[% Data.TicketID %];DestQueue=Junk</Item>
                <Item Key="Target"></Item>
                <Item Key="PopupType"></Item>
                <Item Key="ClusterName" Translatable="1"></Item>
                <Item Key="ClusterPriority"></Item>


ConfigItem/@Name -> "Ticket::Frontend::MenuModule###010-Bulk"
ConfigItem/@Valid -> "1"
ConfigItem/Setting/Hash/Item/@Key="Action" : AgentTicketBulk
ConfigItem/Setting/Hash/Item/@Key="Description" : Bulk update this ticket
ConfigItem/Setting/Hash/Item/@Key="Link" : Action=AgentTicketBulk;TicketID=[% Data.TicketID | html %];[% Env("ChallengeTokenParam") | html %]
ConfigItem/Setting/Hash/Item/@Key="Name" : Bulk
ConfigItem/Setting/Hash/Item/@Key="PopupType" : TicketAction


    <ConfigItem Name="Ticket::Frontend::MenuModule###010-Bulk" Required="0" Valid="1">
        <Description Translatable="1">Shows a link to bulk update a set of common fields in a ticket without a mandatory lock. Additional access control to show or not show this link can be done by using Key "Group" and Content like "rw:group1;move_into:group2". To cluster menu items use for Key "ClusterName" and for the Content any name you want to see in the UI. Use "ClusterPriority" to configure the order of a certain cluster within the toolbar.</Description>
                <Item Key="Module">Kernel::Output::HTML::TicketMenu::Generic</Item>
                <Item Key="Name" Translatable="1">Bulk</Item>
                <Item Key="Action">AgentTicketBulk</Item>
                <Item Key="Description" Translatable="1">Bulk update this ticket</Item>
                <Item Key="Link">Action=AgentTicketBulk;TicketID=[% Data.TicketID | html %];[% Env("ChallengeTokenParam") | html %]</Item>
                <Item Key="Target"></Item>
                <Item Key="PopupType">TicketAction</Item>
                <Item Key="ClusterName" Translatable="1"></Item>
                <Item Key="ClusterPriority"></Item>

Such a way, the resulting url to the bulk-update popup will read something like:;TicketID=43674;ChallengeToken=CcHiHGGowWmfiQeQBNGm6UKjgheTsjCZ und deliver the desired functionality. If you omit the ConfigItem/Setting/Hash/Item/@Key="PopupType" setting, the dialog will not open in a popup but in the parent window.

Different from the behaviour last time, the new user interface element was not immediately visible upon the next click. It took an explicit activation in the OTRS system config (look out for Ticket::Frontend::MenuModule in the group Ticket) like so:


Have fun, Peter

OTRS Dashboard / Widget Customization and Extension Howto

If you happen to find the widgets available for the otrs dashboard, supplied by the default installation, out of line with your in house workflow or just off your needs and taste, here is how to move things further.

Peeking the web for a way to introduce own, self-configured widgets, the top notch hit is (really): , yet another of interest surely: . crythias shows how to start off in general and shares some precious information about the url-parameters available for filtering (not officially shared on

However, for the complete picture, first of all, administration of (initially supplied) otrs widgets can be managed in the admin console. do head, as usual, to: https://myhost/otrs/ and just search for “widget” (so, at least, i got there, other ways may work alike).

Within the result set showing up, find the link to “Frontend::Agent::Dashboard” of group-type “Ticket” (there may be other groups concerning the dashboard):

Upon click, forms of all the active dashboard widgets along a plenty of configuration parameters will appear, the state “new tickets” widget may look as follows:

There are two interesting things to mention here:

  1. The widget identifier, e.g. "DashboardBackend###0120-TicketNew" is what you need to redefine for your own widget definition in /opt/otrs/Kernel/Config/Files/Ticket.xml , or much better / professional in your own new in-house xml-file, Ticket-Local.xml or whatever.

  2. The widget module name has another counterpart in the file system, such that "Kernel::Output::HTML::Dashboard::TicketGeneric" equals /opt/otrs/Kernel/Output/HTML/Dashboard/ . If you do not only want to reinstate an existing widget template with an adjusted configuration but also want / need to hack the widget code itself (a perl module format) for another layout, for example, go there.

Ok, then, some additional Ticket-Local.xml file may turn out to read as follow. Note the new widget identifier in line #3 as well as the adapted where clause url-parameters (attributes) in line #26. Ordering is by column Age, ascending, by default, such that there is no explicit statement required here.

<?xml version="1.0" encoding="utf-8"?>
<otrs_config version="1.0" init="Application">
  <ConfigItem Name="DashboardBackend###0301-PtxSysTicket01" Required="0" Valid="1">
    <Description Translatable="1">Parameters for the dashboard backend of
        the open tickets overview of the agent interface.
      _Limit_ is the number of entries shown by default.
      _Group_ is used to restrict the access to the plugin (e. g.
      _Default_ determines if the plugin is enabled by default or if the
        user needs to enable it manually.
      _CacheTTLLocal_ is the cache time in minutes for the plugin.
      Note: Only Ticket attributes and Dynamic Fields (DynamicField_NameX)
        are allowed for DefaultColumns. Possible settings: 0 = Disabled,
        1 = Available, 2 = Enabled by default.
        <Item Key="Module">Kernel::Output::HTML::Dashboard::TicketGeneric</Item>
        <Item Key="Title" Translatable="1">Live Tickets, ex pending Icinga</Item>
        <Item Key="Description" Translatable="1">
          All new, open, pending etc. tickets, excluding the items from
            Icinga that wait in a pending reminder after a recovery.
        <Item Key="Attributes">StateType=new;StateType=open;</Item>
        <Item Key="Filter" Translatable="1">All</Item>
        <Item Key="Time">Age</Item>
        <Item Key="Limit">10</Item>
        <Item Key="Permission">rw</Item>
        <Item Key="Block">ContentLarge</Item>
        <Item Key="Group"></Item>
        <Item Key="Default">1</Item>
        <Item Key="CacheTTLLocal">0.5</Item>
        <Item Key="DefaultColumns">
            <Item Key="Age">2</Item>
            <Item Key="Changed">1</Item>
            <Item Key="Created">1</Item>
            <Item Key="CustomerCompanyName">1</Item>
            <Item Key="CustomerID">1</Item>
            <Item Key="CustomerName">1</Item>
            <Item Key="CustomerUserID">1</Item>
            <Item Key="EscalationResponseTime">1</Item>
            <Item Key="EscalationSolutionTime">1</Item>
            <Item Key="EscalationTime">1</Item>
            <Item Key="EscalationUpdateTime">1</Item>
            <Item Key="TicketNumber">2</Item>
            <Item Key="Lock">1</Item>
            <Item Key="Owner">1</Item>
            <Item Key="PendingTime">1</Item>
            <Item Key="Queue">1</Item>
            <Item Key="Responsible">1</Item>
            <Item Key="Priority">1</Item>
            <Item Key="Service">1</Item>
            <Item Key="State">1</Item>
            <Item Key="SLA">1</Item>
            <Item Key="Title">2</Item>
            <Item Key="Type">1</Item>

Since otrs does not feature a syntax to express multiple value facets for an attribute, the clause term for a dedicated attribute may have to be repeated as necessary. Do note also, that then domain of actually possible attributes is somewhat undocumented (guide me if you know better). One may browse other widget configurations in /opt/otrs/Kernel/Config/Files/Ticket.xml but there is not much to inspect. We also have this set of attributes shared by crythias on otterhub, like this:

Types TypeIDs CreatedTypes CreatedTypeIDs States StateIDs CreatedStates CreatedStateIDs StateTypeIDs Locks LockIDs OwnerIDs ResponsibleIDs CreatedUserIDs Queues QueueIDs CreatedQueues CreatedQueueIDs Priorities PriorityIDs CreatedPriorities CreatedPriorityIDs Services ServiceIDs SLAs SLAIDs WatchUserIDs

And from the naming scheme we see, may conclude, for example, that there is a StateType, a StateTypes (multi) and a StateTypeIDs (multi-id) attribute. Nevertheless, you may need to test this on the spot, e.g. StateTypes did not work for me, any identifiers from StateTypeIDs originate from the database, look it up there.

Have fun, Peter