...
Make JIRA Client and Deskzilla catch links to issues/bugs from e-mails, web pages, etc., and open them instead of the browser.
I'll refer to JIRA Client for readability, but everything is the same for Deskzilla.
Wiki Markup
- *http\[s\]://jira.mycompany.com/browse/FOO-123* (JIRA Issue)
\
- *http\[s\]://bugzilla.mycompany.com/show_bug.cgi?id=123* (Bugzilla bug)
Wiki Markup
URL Scheme Handlers
Operating systems generally decide which application to use for an URL from the URL scheme alone.
Instructions on registering URL scheme handlers: Mac OS X, Windows, Gnome, KDE.
Mac OS X invokes the handler by sending it the "open location" Apple Event.
Windows executes a shell command with the URL as parameter, or sends a message through DDE.
Gnome and KDE execute shell commands.
...
JIRA
...
Client
...
as
...
the
...
Default
...
HTTP
...
[S
...
]
...
Handler
...
The idea is to make JC catch all http:// and https:// links and forward the non-issue ones to the browser. This is achievable one way or another, but very harsh: JC is launched for any URL whatsoever, it must know or figure out the user's preferred browser. Not humble.
...
The URL http://jira.mycompany.com/browse/FOO-123 becomes almworks-jc-http://jira.mycompany.com/browse/FOO-123, and so on.
URL Rewriting Extensions
The rewriting is done in the user's web browser by a special extension that listens for "open URL" events, checks the URL, rewrites it if necessary, and navigates the browser to the faux URL.
This means we need one extension for every (popular) browser out there. But the same extensions would work across all operating systems (where their respective browsers work).
...
Opening Issue URL on Linux
JC 2.3.4 hotfix 234, DZ 3.0, JC 3.0 support the --open=<URL> command-line parameter (with "real" and "faux" URLs):
| Code Block |
|---|
./jiraclient.sh --open=http://jira.mycompany.com/browse/FOO-123 |
Further investigation:
- Assemble a working solution for Gnome and KDE -- write scripts, or, at least, instructions.