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>
        <Group>Ticket</Group>
        <SubGroup>Frontend::Agent::Ticket::MenuModule</SubGroup>
        <Setting>
            <Hash>
                <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>
            </Hash>
        </Setting>
    </ConfigItem>

using:

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

mapped:

    <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>
        <Group>Ticket</Group>
        <SubGroup>Frontend::Agent::Ticket::MenuModule</SubGroup>
        <Setting>
            <Hash>
                <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>
            </Hash>
        </Setting>
    </ConfigItem>

Such a way, the resulting url to the bulk-update popup will read something like: https://otrs.some-server.de/otrs/index.pl?Action=AgentTicketBulk;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

(Non-)Login and (-)interactive shell invocation loads on centos7 – a status

Setting up an enriched, system-wide prompt again raised the question where to put the definition code. Spreading the snippet all over the home-located profile-(.bash_profile) and resource(.bashrc)-files is a bad idea, tedious to maintain, you know, don’t ever think about it.

Changing the global profile- and resource-files (/etc/profile , /etc/bashrc) won’t be of any much more brain either, since yet another system update may cause conflicts with the maintainers version. Just reading along the web, I found that there is some mechanism integrated with /etc/profile to source homebrewed definitions from a file within /etc/profile.d . Great, this is what I want, but, as far as I remember correctly, a profile will only be sourced once, upon login, in a login shell, right?!

Oohhm, still can’t recite that poem on command. On login, we source the environment (profile). We won’t do that for sub-shells because the environment will be derived. However, since a login shell is also an interactive shell usually, we still addionally source the aliase- und function-resources as well… And so on and forth in bare theory, which has been depicted nicely in man bash, in the invocation section in particular. Read this now for reference!
On the other hand, living system may not stay with the initial ideas very long, in practice a question may have a multiple of answers (or the other way round). So I parsed and instrumented the profile- and resource-loading process to see what really happens under the bonnt. See what I’ve found.

Presenting “Analytic Functions in Practice” at the DOAG-Regio Hamburg/Nord Dec 4 2018

Save the date to see my presentation about “Oracle Analytic Functions in Practice Applications” along the regular meetup of the DOAG/Oracle-community in Hamburg on Dec 4 2018. Although analytic functions is nothing really new in the Oracle world, I’m again attempting to propagate the thrilling productivity of this SQL-toolset, since practice applications are still not as dispersed as expected. To this extent, I want to stress windowing and aggregation over analytics and statistics in real world scenarios and examples. The presentation will be held in German, I suppose. Event details go here and there:

• https://www.doag.org/de/events/regionaltreffen/hamburgnord
• https://www.doag.org/de/event/eventdetails/569110

A Confluence dashboard-like page layout using section-, column- and panel-macros

Every wiki landing page usually features a kind of overview layout to provide links to the most interesting topics or articles. This might constitute a classic table of contents, quite lengthy at times, a tag cloud of the hottest keywords (and relations, maybe), for iterative exploration, or, if you like, a dashboard of context grouped / block visualized widgets of important articles. Whatever you prefer, me, I almost always take on the dashboard approach, because it provides a great productivity in information to space ratio. Furthermore, dashboards also greatly serve the figurative memory in that one can plainly remember some article link resides in a widget up in the upper right corner of the page or yet within another widget with an outstanding background color.

However, I’m not planning to advertise dashboard / widget user interfaces here. What is to follow comprises an implementation pattern and example of setting up a simple dashboard layout in recent Confluence environments. All you need is to employ section-, column- and panel-macros in that order and hierarchy, respectively. For reference see the latest Confluence docs concerning:

Flashback version query and the proper use of timestamp and scn clauses

Flashback version query essentially enables you to lookup the incarnations of a row (defined by primary key) in the past, in a consecutive manner. Version information is depicted by a couple of pseudo-columns, namely versions_xid, versions_startscn, versions_endscn, versions_starttime, versions_endtime and versions_operation. See Using Oracle Flashback Version Query in the docs for explanations.

In combination with flashback query or flashback transaction query, one may restore a row incarnation from the past into a new table or even rollback to a past row incarnation within the same table.

This article will discuss flashback version query together with flashback query to restore one to many rows, just shown for a row of a unique key here for brevity, detailing when and when not to use timestamp and scn select where clauses to prevent pitfalls. An example table / dataset will be given, representing a real world scenario where some past data needs to be identified first and is then to be made available again.

Flashback version query uses the following pattern, including the pseudo-columns introduced above, on an actual application-, but not a system-table (alike flashback transaction query). A timestamp– or scn-range must be supplied to define the lookup window (defined by the stock of the available undo-data, remember) and to actually populate the pseudo-columns, respectively: