Am I an Atlassian Lassie?

WTF? Once upon a time I wrote applications, I wrote web-apps, I created databases. Times change. I seem to be spending much time in the Atlassian eco-sphere, slowly sinking deeper and deeper into the API's but do I have the time!

The recent Jira 3.13 upgrade bust my previously unpublished email interoperability fixes to plug the gap between Jira inbound email support for issue creation and my companies nefarious Exchange server and user email configurations. Why care? Well, Confluence has no 'nice' way to interface Jira, its either one webapp or another. Confluence has nice macros like {jiraissues} and {jiraportlet} which rock (ok, we forgive almost current IE6 CSS problems in the macro), there is just no nice 'form' to create issues. It is however possible to email issues into Jira. But.

The problem is that we have multiple email formats, some of which are 'aliases' and not the 'one' that is in the mail attribute. Oh, and depending on which email client you use, it can change from that too. So basically, the Jira function was useless unless I could fix this. Rather than just patch my code and move on, this time, I decided to do it a little more 'properly' and create a framework that fixed all my problems, allowed extensions for other formats of inbound mail and kept such tweakery separate from the issue creation code. This got published Extendable Mail Handler. Currently, it only has an implementation that makes it compatible with Form Mail Ng, if only that worked with the current 2.[8,9] releases, 2.10m3 seemed to work fine, so fingers crossed. Here is a FormMail Ng example form for interest.

As the EMH integrates with LDAP, I've been continuing to work on and around the LDAP Util library, making great use of the Beanshell plugin to embed a few SQL queries and LDAP lookups, combining with the fabulous Run macro to do parameter replacement. The result is a fully interactive series of pages allowing users to easily search for an LDAP user, Confluence group, Jira group. I need to add a few screen-shots to do it justice. As I've almost entirely delegated Confluence Space management to users (thanks to CSUM) this last piece gives them the solution that thorny question 'who is in group X' how do I give access to user Y. Keeping the solution in the Confluence bubble should help.

A while back I tried to import a Twiki site from another area of the company using the Universal Wiki Translator for Twiki. As with most online translators, YMMV. In this case I managed to hit a a bug preventing upload from the off (seems to be a talent of mine), some pages got uploaded seamlessly, others were complete dross, all told 3500 pages got loaded, only later did I discern that some data was cruft and broke the XML export (I think). Man that was a couple of days of delete from ... INNER JOIN ... WHERE hell. I think I finally got down to the last 7 rows of data but got bored, well, scared, I think I finally had to remove foreign key constraints in order to remove circular referencing data. I'm not quite brave enough to try that live :) Anyway, back to the point. So we have a twiki system, its works well for those guys, and I have to say, it has one killer feature that Confluence is still scratching around for, forms. So simple, so elegant, so killer-feature. If you don't know about this, imagine a form on a Page, set some values through radio buttons, select drop-downs with images etc, hit 'save', the data gets saved, fine, but in a database from which tabular data can be extracted at a higher level. OK so, there is Scaffolding and Meta data2. Its getting there, just lacking maturity if compared to Twiki. Soooo:

Integrating Twiki data with Confluence? Hmmm, {html-include} would appear a useful ally but there's a problem, Twiki, like other sites uses relative URL's extensively, and guess what happens when you import from twiki.server.net to confluence.server.net? all the twiki links point to non-existent URLS on the confluence server. The solution seemed straight forward, and thanks to readily available source code I wrote my first non-library Confluence plugin, taking just a few hours to rewrite the URLs of relative links. Its not posted anywhere yet in its own right, but it got posted under CONF-13365. As ever with such things, it works out much better if someone else is always maintaining the code!

Continuing the LDAP theme. Having had my appetite whetted by how easy my first macro was, I fancy something UI'ish, and am mid hack converting the 'livesearch' macro into a 'liveldapsearch' macro. The original authors have done all the hard work, theoretically its just a slice and integration dice with the LDAP Util library and voila, useful dynamic ldap lookup (hrm, with no Beanshell).

Oh and then there is the ongoing grief associated with having to setup per-space inbound email account details. That sucks. Having written tooling (using The Confluence SOAP library to automate most of this) there is little payback to 'fix' this, however, the Confluence Mail Utilities Plugin fixes this in a neat way by essentially writing the bit of code that Confluence should have already to pull in all mail and deal with it once rather than have one config per Space. For info, my mail server is polled Continualy thanks to 60+ space email configs. A single poll is actually all thats required if you are smart about it. As usual that Confluence Mail Utilities Plugin wont work for me, so once again Im picking up a scalpel for some LDAP surgery.

And again speaking of LDAP, For a good while now I've been irked at the non-availability of the enterprise feature that is LDAP server failover. Goddammitalltohell, single points of failure should be avoided. In my org, stuff gets turned off. 'ping ping ping' goes my inbox. truly, how hard is it to add such a feature? I don't half feel stupid explaining that the Enterprise system we use can be configured for multiple LDAP repositories but isn't bright enough to identify them as failovers and people have to deal with seeing multiple instances of each other in the People Browser? Gah. One small vote for an issue, one even smaller step for an implemented feature!

That said, I love the products, its the overhead that gets you, we seem to now have all but 2 of them, any month now I'm gonna shout H O U S E !.

And finally to the title, with all this stuff going on, I seem to be spending all day every day doing this stuff, making me officially, my companies Atlassian Lassie :)