ST to RT Investigation: Factors for success: Assessment in RT 4

Following are assessments of RT 4 as regards our critical, important, and nice-to-have features in ST.

Critical Factors and Features

Tracking time spent, with a convenient interface (ie, not editing the total time worked)

• Yes: built in to RT4. Very flexible. With a plugin addition on the production server, will give us a near replica of st-time-tracking for a week view (with added convenience features for adding time for particular items on days)

Ability to view all tickets in queue, not just ones you're involved with

• Yes: users belong to groups; groups can have arbitrary read/write access on queues. Requires giving Lisa the ids of users to have queue access

Item dependencies and see-also

• Yes: built in to RT4 (6 relations, including Parents/Children as separate from Depends-on/Depended-on-by. Dependencies MUST be resolved for the parent to be closed.) Nested dependencies are NOT displayed on an item.

Ability to update tickets via email

• Yes: via rt-mailgate - depends on Subject line including RT #

Attachments to related documentation- uploading files, as well as links to private/public files.

• Yes: first part built in to RT4. Limitation: 3.8MB.
• Yes: it produces a link to private files, which have semi-random URL
  • two attachments on one ticket, created within 5 minutes of each other, on ticket # 525677:
    • /Ticket/Attachment/8455987/4560608/rio-2016.jeg
    • /Ticket/Attachment/8455989/4560612/Waiver_Canada.pdf
• Maybe: link to pubic files - probably requires saving them elsewhere and referencing them in the ticket. as per instructions for larger attachments.

Auto lookup barcodes in inventory and hostnames in inventory and DNS, fill in corresponding info and room number, warn on typos, canonicalize hostnames, link barcodes and hostnames to inventory

• Yes: will require customizations.

Auto lookup users and email addresses, canonicalize, show real name, link to WatIAM, warn on typos

• Yes: IST-built extensions that use LDAP data to validate email addresses.
• interface will do match on users; but you can hand-enter CCs with bad users if you don't pay attention to the auto-dropdown

Handle simultaneous update by multiple users of multiple fields in the same request without locking or losing updates

• Yes: doesn't lock fields.
• Yes: most fields are to add new rows to the database, eg., additional comments, additional dependencies.
• Caviat: some fields can be replaced if a second person edits. Eg., second person edits the title, and the first person saves with the old title, it will save the old title and report back to the first user the old/new values of everything that changed, including the overwritten title.
  • So the users need to pay attention to the report of what changed - it isn't as obvious as in ST.

Sort search results by due date, date created, or last acted (or any field displayed)

• Yes, built in to RT4; can customize search result columns included computed fields (requires minor coding).

Arbitrary SQL searches (e.g. date_created>unix_timestamp()-3600*24*7 and subject like '%print%') with ability to bookmark and API (e.g. needed for Bill's run-on sentence)

• Second part: yes: custom searches can be saved and bookmarked; as a URL, custom search could be used programmatically.
• First part: No- custom searches are just "SQL-like" - not full SQL. Queries will do intelligent things with dates, eg., can determine "last month"; there is a config mechanism for recording University holidays.

Important Factors and Features

Flexible search; if possible, ability to include SQL (eg., Fraser will fine-tune search query with SQL wildcards such as "evergreen%MC%3007")

• No- see directly above: custom searches are just "SQL-like" - not full SQL.

API so our inventory system can continue to report on related work items

• Yes, built in to RT4. Also, flexible command-line tools.

Custom field, for subscription code, that we can easily extract work-hours on particular codes, and replicate the ST functionality within the "subscriptions" database.

• Yes: custom fields available in RT, and ability to search for matching values
• Accessing the "subscriptions" database will require either programming to call the RT API - or query the database from command-line, which they can give us access - or they can email us data daily/weekly.

Recording data to allow budgeting / managing spending using cost-estimate (and keywords and dependency trees - such as summing cost-estimates including dependencies)

• Yes to custom fields.
• summing cost-estimates including dependencies will need command-line queries.

Direct access to the uploaded attachments, eg., smbmount

• No: if we need direct access to uploaded attachments, we would want to store them in our own SMB-mounted filespace and reference them as URLs in RT.

Arbitrary choice of columns and their order and optional abbreviation in search results with ability to bookmark and API

• Yes: Ability to make arbitrary dashboards

Batch dependency creation with particular fields set to arbitrary values

• Maybe, but not by May: requires adding custom code (and Best Practical would like a copy of what we come up with).

Nice-to-have Factors and Features

Command-line access to perform searches and updates

• Yes: offered by IST.

Automatically turn ST#nnn into links in comments, see_also, and dependencies. We won't import our existing ST corpus into RT. So, we'll be using a mix of both systems for some time.

• Yes to "see-alsos" linking to arbitrary URLs. Shortcut URLs for ST will require custom code (fairly easy).

Search both ST and RT from a single search page. It's not uncommon for searches in ST to find relevant tickets from years ago, e.g. the lifetime of a machine or Ubuntu long term support release (both about 5 years).

• Probably not.

Parking-Lot for Identified additional Factors, Features, and issues

See also ST To RT Requests And Issues for a list of items we might bring to Lisa/Jeff.

• 2016-08-30: emailing RT: if you have email aliases / reply-to which is different from your regular userid, RT will create the item with the wrong user.
  • 2017-01-27: Daniel: this is in-process to be fixed by Jeff/Lisa. This Tuesday they asked whether this was higher or lower priority than rolling out 4.4; MFCF was very clear they wanted the custom roles in 4.4 so this will probably happen after that. In the meantime we can manually update tickets to change the requester/workers in our queues.
• 2016-08-30: Factor: need in-house expertise to customize RT front-page / dashboards / search page.
  • 2016-12-02: Daniel: yes- this is straightforward through experimentation. What dashboards do we need?
• 2016-08-30: RT doesn't have a summary field.
  • 2016-11-22: Lisa has added this - we will re-add it in dev and reformat the CSS so it appears wider.
• 2016-08-30: can RT create dependencies via email?
  • 2017-01-27: Daniel: not currently; we can request having an extension installed for this ( https://metacpan.org/pod/RT::Extension::CommandByMail )
• 2016-11-14: if we're working on an item that is handed off to an IST queue, is our viewing access limited to those *CF people who are workers/CCd on the item?
  • 2016-11-22: Yes, for some queues such as security. For others, they plan to (or have) expand visibility of some IST queues to include campus tech staff.
• 2016-12-08: nice-to-have: finer granularity of security: grant/deny group read-access per transaction on a ticket?
  • 2017-01-27: Lisa says that some queues have a custom field for private comments which are not visible to requesters; we should let her know if we'd like it for our queues.
• 2017-01-11: how do we want to handle existing active STs? When is the cutoff for making updates in ST? May 1 or much later? (former requires making a LOT of corresponding items in RT. discussions to follow).
• 2017-01-23: RT's default roles are simpler than we use in CSCF and MFCF. Only one Owner; merging "other owners" with "Admin CC" and discarding "Responsible" field. Discussion continuing - do we use RT's default roles for now, and consider custom roles at a later date, in conjunction with IST?
• 2017-01-27: want unambiguous instructions for getting emails into an existing RT, possibly even on item's page like ST has.
• 2017-01-27: want ability to edit history, or at least scrub a correspondence transaction to recover from inadvertent password paste without having to bother Jeff.
• 2017-04-20: See also ST To RT Requests And Issues