RT 4.4 Training

Jim Brandt <jbrandt@bestpractical.com>

Day One (Training)

4.4.1 current; 4.4.2 will be out in a few months.
new:
* assets integrated (Reed College contributed to put this into core)
* attachments on disk or in cloud (dropbox or S3; not Nextcloud)
* popout ticket timer
* custom roles
* ExternalAuth and LDAP Import
* file upload interface
* existing attachments reused on reply
* “infinite scroll” for loading ticket history - option to not load entire thing
* default values for ticket fields
* SLA tracking integrated
* missing attachment warning
* keyboard shortcuts

priority: numeric; can have cron job to auto-increment each day
config: custom field grouping: put under a new heading (such as custom, and Dates, Basics, 2 other sections)
- also custom fields on users, and custom grouping

reminders- on ticket. subject/owner/due - scrips run on them.
- CSS to collapse by default

hiding things: user preference: ticket-display -> hide unset fields - default no; if on, shortens page.

people: core to controlling behaviour. relationships.
- Roles: custom roles: can add rights, eg. also, name as “manager”. can automate switching owner based on queue. yes, you need to customize existing scrips for, say, sending email to custom roles.

dates:
- started: is set when status changes from new to opened. can be useful creating report on assigned tix without work.
- * Do we want to automate new->opened upon comment/reply? (vs. close automate re-open on comment: off)

states: new/inactive/active. stalled is inactive by default - searches by default don’t include. can modify search to include stalled. (can have weekly cron to specifically look for stalled). eg., can make dashboard to find all stalled so director can bring this up with other directors.

diversion on life-cycle: docs -> user… -> lifecycle
- can set search to __active__ to match all things in active states (or __inactive__ )

dates continued:

• due: can be auto-set according to SLA; auto-unset on reply; or total-response 3 days-> can set to LESSER of total-SLA or response-SLA. (not sure there is per-item unset SLA)
  • module for Business Hours: “8 business hours” = set appropriately. Can specify holidays manually- someone enters u holidays in configuration.

• 1) can make visual indications of SLA nearly coming due- via css class; or 2) send email sent to different-addresses based on support-team; management-team; …CEO? 3) working on slack integration
  • configuration: Automating rt-> rt-crontool -> "commenting and corresponding on ticket" -> RT::Condition::Overdue

requestors: can create new items with individual as requestor, easily; also search for item; and their tickets; user info page can also have custom fields set; and pull from LDAP (weekly on campus)

links: in strictness order. refers-to can be link.
- eg., their internal system refers to external public system "issues"
- code to auto-complete based on subject? (currently “refers to” does lookup within its database)
- "helpers" do AJAX search
- also in text, can do auto-convert "clicky" (conv with jav)

[break: talked with Adam Savage from library; down to 1.25 person with him .75 seconded out; need some form of inventory. Very interested in RT's]

keeping track of tickets: can bookmark tickets (star icon); shows up on users default list on main page
ticket timer can have multiple open at once…

History section:

• now templates can include HTML-formatted email (with plaintext option)
• user default show history -> auto-scrolling option
• colours on left-hand side: indicate type-of-transaction as per header
• extension on CPAN- can filter history elements displayed on main page (vs. history tab which shows all).

Actions menu next to bookmark:

• can restrict status-change options here based on workflows;
• articles: can be: 1) reference for internal staff; 2) write for end-user - automatically populate dropdown.
  • extension to turn articles into templates (article::template); may become core, currently in CPAN.

Admin menu

• * jav is happy to give me admin rights on the dev instance (once they’ve removed 90% of the data).
• custom role: can be single-user or multiple-users; can have a (admin) description; (user) entry hint (shows up in grey).
• new queue: has a “lifecycle” - e.g.., default, incident_reports, incidents, countermeasures…)
  • If change a queue’s lifecycle, need to finesse changing the status of existing items - eg., orphaned unless status exists.

group rights: options for everyone vs. unprivileged vs. privileged

Custom Fields: interdependence: eg., cities depends on state.
- can set default values (useful for entries from email)
- can include data from a separate URL based on __item__

Approvals: change in status requires action by certain users- creates a depends-on relationship (which blocks further action until approved).
- could have approvals depend on admincc

Dashboards: users need rights to dashboard; and also to the saved-search.
- we will want to make a saved search with Status = '__active__'

shortcut keys: shift-? will display.

search queries:
- relative dates: 'now - 7 days'
- can be used as a rolling window in dashboard; can also make a scheduled dashboard which will send you an email.
- ticketSQL
- tomorrow: column-map to munge data before displaying.

read later: https://bestpractical.com/blog/2016/3/improved-time-tracking-in-rt re:
https://metacpan.org/pod/RT::Extension::TimeWorkedReport

fhgunn asks: 3 queues? / implications of working across queues?
did I record above: looks like we can display a REST result in the item page?

Scrips
- can automate just about anything RT does
- /Admin/Scrips has list (visible to admins)
- scrip can rely on existing conditions.. or user defined conditions and results
- here be complexities: scrip might fire repeatedly when there are multiple transactions on an item
- can consider adding automation to existing work
- keeping multiple systems in sync
- can apply globally or to a particular queues.
- can manage what order they run in, as of 4.0 (including per-queue vs RT-wide)
- notifications: customizing on a queue: if a template is named the same as a global-level queue, the queue one will take precedence.
- (grant permission so an admin can modify their own queue’s: “View/Modify Scrip templates” in the queue)
- scrips can run sub-processes via shell (e.g. to call to other programs)
- Q from lisa: scrip running in normal mode vs. batch: if multiple transactions at same time. Batch mode runs last.
- scrip can create transactions too.
- batch mode can reference other transactions that happened directly beforehand.
- run as normal-mode usually, but run in batch mode if problems.
- RT::Extension::AdminConditionsAndAdctions (will become core- web UI for managing RT conditions and actions).

Attachments
…
Assets
Catalogs = queues.
customize fields easily; validate formats; link existing tickets or new tickets
- reed college is big installation; certified mac reseller they do all their mac sales/loans out of RT. GSX syncing for Apple warranty lookups.
- Hamburg user: using assets to track people, because finer grained
- Q: assets > 100k? millions transactions per month can also scale to assets.
- could invoke RT scrips to update assets automatically. (doesn’t directly have equivalent of scrips)
- assetSQL - coming soon, possibly 4.4.2
- extension to bulk-upload csv
- working on REST2 API but not yet.
- bulk updates: similar to RT’s bulk update: select the items, apply the set value
- Articles
- Very easy to turn a transaction on an RT into an article, and label with the subject and category or categories.
- Some roadblocks before RT will have articles turned on.
Tags ?

Day Two (Consulting)

Seeing in action: RT::Extension::AdminConditionsAndAdctions - has documentation on conditions and actions.

Notify.pm accepts lots of options to send email; used by Actions. Saw
Ask Jeff: action: are we using “send owner and adminCcs” instead of separate actions- so we don’t get duplicate emails?

Time worked
built extension to record time worked
RT::Extension::TimeTracking
- Add to time worked: date (to log time for yesterday)
- “Users:” see total time worked per person

- RT::Extension::TimeTracking::Automatic - configurable, add n minutes for basic overhead on particular extensions
- q: can we automatically aggregate time on parent/child? sort of. There’s a core built-in to add time to parent ticket (though it doesn’t add things from tickets ADDED to parent

- “time sheet” view: MyWeek then has a time-sheet to view and edit time-worked for a week

• NOT customizable for longer than week, but he thinks Charts might be able to do custom query for “term”

- time-worked comment not currently visible to unprivileged users (clients) - though time amount added is visible
- diversion: RT_Config.html has a zillion options available; they don’t want to add more; might not

ticket_metadata.html has docs of what the fields are used for.

Charting (photos) will give us slicing and dicing for time-worked on arbitrary time-ranges.
Reporting / Query Builder

- interesting note about dates: > January 1 includes Jan 1, because > midnight on Jan 1, and converts to seconds. Or can do >= or add time “2017-01-17 19:00:01” (both in advanced)

• search results: column maps
  • Display columns: Time Worked - is in human-readable form.
  • search_result_columns.html - Column Map Callback

validating data
- DNS and/or IP
- autocomplete javascript: “helpers” - rip out guts from examples (back-end and front-end)
- what to do with the data? perhaps onChange() event that displays below field, eg., with red text if doesn’t match. possibly store in a separate field.
- or, callback to run on save (which displays at top of page). Modify.html approx line 80; add callback and say skip_update = 1; results = array including error.
- where to put this code? local/ (one-off files). and possibly local/plugins/ see writing_extensions.html
- custom field: how to populate in page: need “RT::Interface::Web::GetCustomFieldInputName” - probably need assistance from best practical to implement.

rt-extension-timetracking extension:
- look at code for sample making HTML pages, and using callbacks (which won’t mangle on updates).
- eg., extending EndOfList which runs at the bottom of a list.
- html/Tools/MyWeek.html - steal liberally. interpreted Mason.

• how to include the new page in menus?
  • callbacks in tabs html/Callbacks/RT-Extension-timeTracking/Elements/Tabs/Privileged
  • arbitrary new menus under existing. need unique name, suggest standard across UW.
  • sort order: leave blank for last; count and add .5 …
  • could include html to set a class id (to distinguish visually) using attributes parameter

diversion: adding “!updateStatus” as a column (with link…) will add a display column for “is there new activity on this ticket?”

[ lunch: 4.4 isn’t going into production until roughly may. so we should be probably doing dev for 4.2
handling “time on items we don’t own any more” - mpatters RTIR investigations definitely require us making our own transactions anyway. Probably we want to make sub-items to hand off to IST? policy decision.
]

question about ticket locking: RT::Extension::TicketLocking to place advisory locks on tickets.

• modifying visual fields:
• applies to all queues by default.
• css or JS inclusions . RT uses jQuery. … options:
  • 1) local/static/jssfile
  • 2) admin tools theme - can add CSS there- or put in javascript. - can use for testing before putting into 1)
    • probably safe using hard-coded ID eg., textarea.CF-19-Edit { width: 500px important; }
    • if used in other queues they probably use the same ID; if you need the field to only be different for one queue, you’d need to modify the Mason template.

textarea.CF-129-Edit { width: 400px important; }

Remove duplicate email sent when ticket owner changes (currently 2 emails are sent to the new owner when the owner changes in RT)
- Admin/Scrips/

creating sub-items in batch
- requires new page. he’d link off “Actions”
- Ticket/Create.html - crib code.
- Tools/Offline.html - is sample. look at 4.0 source (not 4.2)
- share/mason/TicketDisplay/Display.html
- what queue? offer dropdown
- or ticket->queue->id instead
- loop to update args (outer loop gets subject; inner loop gets args)
- links section has possibly cribbable code as well. CreateTicket … CloneTicket …

turn RT# or ST# in text, into Links:
- via makeClicky (talked about it yesterday)

Parse email to operate upon RT item
- and populate custom fields and/or perform perl actions like scrips.
- RT::Extension::ExtractCustomFieldValues
- see CustomFieldScannerExample template
- eg., WCMS forms -> RT items

wufoo.com form builder

Custom Field Asset Type-> Link values to
- tested in CS-RSG - look up barcode

pulling values from external db
https://docs.bestpractical.com/rt/4.4.1/RT/CustomFieldValues/External.html

- possible json lookup in inventory:
https://cs.uwaterloo.ca/cscf/internal/inventory/web/inventory/?r=inventory/json&id=16863
{"hostDomainName”:”,,,[…]l,”systemDescriptionDate":null,"unit":"CS","vendor":"ONWARD","warrantyStart":"2002-12-01","warrantyStop":null}

-- DanielAllen - 2017-01-19