...
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 schemes:
- almworks-jc-http, almworks-jc-https (JIRA Client HTTP/HTTPS)
- almworks-dz-http, almworks-dz-https (Deskzilla HTTP/HTTPS)
The URL http://jira.mycompany.com/browse/FOO-123 becomes becomes almworks-jc-http://jira.mycompany.com/browse/FOO-123, and 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).
Available extensions:
- Google Chrome -- ALM Works Connector for Chrome (prototype0.2.1)
- Mozilla Firefox -- ALM Works Connector for Firefox (0.1, functionality of Chrome's 0.2.1)
- Apple Safari --%nbsp; ALM Works Connector for Safari (0.1 prototype)
Needed extensions:
- Mozilla Firefox (3.x and 4.x?)
- - Internet Explorer (terra incognita)
...
It seems like Mac OS X sends the "open location" to the URL handler, but not the "activate". This means that when JC and Chrome are in different Spaces, JC would open the issue, but the space wouldn't switch.
The lab-tested workaround is to use a separate tiny AppleScript application as the faux URL handler, that would also send the "activate" to JC.
Fixed in JC 2.3.4 build 5825.236. It sends "activate" to itself through the AppleScript engine for javax.scripting API (requires Snow Leopard with Java Update 3),
You can also use the command line:
...
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.