The Worklog Assistant Blog

Logging time to sub-tasks only in JIRA using custom scripts

noreply@blogger.com (Sohail Somani) — Tue, 15 Jan 2013 20:16:00 +0000

Hello and welcome to another edition of "Stuff you didn't know you could do with Worklog Assistant."

As referenced in a previous post, custom scripts are a nifty way to extend Worklog Assistant to perform issue-specific housekeeping tasks.

For example, I use custom scripts to create and merge branches for a given issue. This is done through a "Context menu" script which allows me to add custom commands to any issue:

One of the recent additions to Worklog Assistant are a couple of new of "hooks" (in the Emacs parlance) or "extension points" (in Eclipse-speak).

The new hooks (can you guess what editor I use?) allow you to run a script when you toggle the timer on an issue and/or run a script once a minute.

People are already using them! Michael van Engelshoven was kind enough to share that he uses the new functionality to generate a git commit template:

With the output looking something like this:

But that's not all! As the title of this post suggests, it is possible to use custom scripts to prevent yourself from accidentally logging work on issues that you should not log work on. For example, against issues that are not assigned to you. In this case, I will show an example of how you can generate an informative message when you unintentionally start logging work against a sub-task.

So a quick review:

Custom scripts work by executing platform-native scripts
Custom scripts are executed in response to different user interaction (none, explicit, implicit, etc)
All properties of the current issue are exposed through environment variables. For example, the summary field of an issue is exposed as the variable JIRA_Summary
Scripts that have a non-zero exit code are assumed to have failed and the user is notified.

Putting these together, we might guess as to how to prevent a user from tracking against an issue that is not a sub-task:

Create an "Issue Timer Toggle" custom script (the name is horrible, sorry)
Detect if the issue is a sub-task
If not, the script should fail with an error message

And that is exactly what is done here:

The script is specific to Windows but it can easily be modified for other platforms:

@ECHO OFF

if "%JIRA_IsSubtask%" == "0" (

echo ---------------------------

echo %JIRA_Key% is not a sub-task!

echo ---------------------------

echo Please choose a sub-task

exit 1

)

When I toggle a timer on an issue that is not a sub-task, I am greeted by this message, fully customized by you!

This wraps up another edition of ~~"Cats riding invisible bikes"~~ "Stuff you didn't know you could do with Worklog Assistant." To find out more, check out the documentation on custom scripts. As always, have a nice day and feel free to contact me with any questions, comments or suggestions!

No post is complete without a funny picture of a cat so here is a coder cat:

New Release - JIRA 5 support announcement and other stuff

noreply@blogger.com (Sohail Somani) — Sun, 03 Jun 2012 20:53:00 +0000

So it's that time of year again. New blog post! Don't you worry, releases have been occurring frequently even without blog posts. I have just gotten a little behind in updating the blog :)

The biggest change since the last blog post is JIRA 5 support. And the biggest implication from the user's perspective is that you no longer need any server-side plugin to access the "extra" data that we needed to before. Yay Atlassian! I'll be happy to retire that thorn-in-my-side at some point.

Besides that, a whole bunch of stability-related fixes have been included which should make Worklog Assistant run much longer and better for you. I not-so-infrequently get people emailing me telling me that they have left Worklog Assistant running for months! So to the few of you who have been having some problems (Mac users especially), you should be much happier. I couldn't have done it without the help of some very helpful customers who sent me log after log and tested build after build. Thank you! Here is a cat riding a bike for all your hard work:

In implementing the JIRA 5 support, I was able to clean up a lot of cruft and I am very happy with how things have turned out. I also brought in some code from v2 which was nice.

Check out the Atlassian Marketplace listing for Worklog Assistant. Leave a nice review for li'l ol me if you feel up to it :)

Happy time tracking!

New Release - Grouping in timesheet - 1.0.1891

noreply@blogger.com (Sohail Somani) — Wed, 05 Oct 2011 18:58:00 +0000

This release features grouping by various fields in the JIRA user's timesheet. Why is this important? Well, let's say you have a client who prefers you only work on critical/blocking issues because you're a superstar. This is an easy and quick way to make sure that you are adhering to this policy as much as possible.

So how does it work? It probably couldn't be simpler!

Navigate to "Timesheet" tab
Select a field in the "Group by" drop down

For example, I am grouping by "Status" here:

This view is a good way to make sure I'm actually getting some work done!

Other changes in this release include a server-side plugin, a signed Windows/Mac installer and some bug fixes (grumble, grumble.)

Happy time tracking!

Custom Actions - Exporting Worklogs (part 2 of 2)

noreply@blogger.com (Sohail Somani) — Mon, 05 Sep 2011 03:33:00 +0000

In the previous post, I gave a couple of examples of customizing the Worklog Assistant context menu items to script actions for a given issue. In this post, I'm going to talk about how to export JIRA worklogs using the same functionality. Geek credentials are still recommended, by the way.

At the moment, Worklog Assistant only stores worklogs for the current user to simplify storage requirements. So when we are talking about exporting worklogs, we are talking about exporting them only for you.

The general algorithm for exporting worklogs goes is as follows:

script = getUserScript()

worklogs = getWorklogsForDisplayedPeriodInTimesheet()

for worklog in worklogs:

	if not worklogHasBeenExportedByScript(worklog,script):

		env = getEnvironment(worklog) # also issue

		executeScript(script,env)

The key things about this algorithm:

You have to choose the script you want to use.
Worklogs are only exported for the displayed time period.
A worklog is only exported if it has not already been exported by this script.

So let's define a custom script that creates a new file: ~/worklogs.csv. The script defined here will work on Mac and Linux so Windows users will have to translate. What we want to do is create a report that collects all our worklogs for a given time period.

The script itself is quite simple and is shown below:

if [ ! -f ~/worklogs.csv ]; then

echo "Key,Summary,Start date,Time spent (seconds)" > ~/worklogs.csv

fi;

cat >> ~/worklogs.csv << END_WORKLOGS

${JIRA_Key},${JIRA_Summary},${JIRA_WorklogStartDate},${JIRA_WorklogTimeSpentInSeconds}

END_WORKLOGS

If we add this to our custom script configuration, this time changing the type to "Worklog Export", it should look something like this. I named it "Export to CSV":

To use this new script:

Navigate to the "Timesheet" tab.
[Optional] Import -> Import Worklogs. I like to use the query "jql: updated >= -4w" to make sure I have the latest data.
Export -> Export worklogs using custom scripts
Choose "Export to CSV"

Your file will be located at ~/worklogs.csv. Open it now. You should see all the worklogs for the issues you worked on that week, along with the worklog comments.

Try exporting and reopening the file again. You will notice that the file has not changed. This is deliberate. When Worklog Assistant exports a worklog, a note is made that the worklog has been exported. This way, if you are exporting worklogs for reporting purposes, you do not need to worry about accidentally including double entries.

If you would like to delete the notes on exported worklogs, navigate to:

Windows: %APPDATA%\Worklog Assistant for JIRA
Mac: ~/Library/Preferences/Application Support/Worklog Assistant for JIRA
Linux: ~/.config/Somani Software/Worklog Assistant for JIRA

Then, navigate to the "Exported Worklogs" directory and delete the "Export to CSV" folder. That will get rid of the notes and you can run the script again.

Just as before, there are a set of available fields for each worklog. For convenience, I've included the list as well as example values below.

JIRA_Assignee=sohail
JIRA_Created='Tue Dec 30 17:56:26 2008'
JIRA_Description=-
JIRA_Due_date=
JIRA_Global_Rank=46
JIRA_ID=10124
JIRA_Key=TRACKER-51
JIRA_Original_estimate=0m
JIRA_Priority=Major
JIRA_Project=TRACKER
JIRA_Remaining_estimate=0m
JIRA_Reporter=sohail
JIRA_Resolution=
JIRA_Status='In Progress'
JIRA_Summary=Blogging
JIRA_Time_spent='40h 1m'
JIRA_Type=Task
JIRA_Updated='Sun Sep 4 23:15:24 2011'
JIRA_Votes=0
JIRA_WorklogAuthor=sohail
JIRA_WorklogComment=
JIRA_WorklogCreated='Sun Sep 4 12:27:55 2011'
JIRA_WorklogGroupLevel=
JIRA_WorklogID=14933
JIRA_WorklogIssueID=10124
JIRA_WorklogRoleLeveLID=
JIRA_WorklogStartDate='Sun Sep 4 11:28:08 2011'
JIRA_WorklogStartDate_TimeT=1315150088
JIRA_WorklogTimeSpent='1 hour'
JIRA_WorklogTimeSpentInSeconds=3600
JIRA_WorklogUpdateAuthor=sohail
JIRA_WorklogUpdated='Sun Sep 4 12:27:55 2011'

That's all for custom scripts for now! Please feel free to contact me at support@worklogassistant.com or comment below if you have any questions!

Custom Actions - Adding Menu Actions (part 1 of 2)

noreply@blogger.com (Sohail Somani) — Sun, 04 Sep 2011 18:57:00 +0000

A recent update of Worklog Assistant added the ability to export your JIRA worklogs using a custom script. The documentation however, is a bit terse. If you are interested in extending Worklog Assistant generally, this will give you a good introduction. You must speak geek to read this blog post. If you cannot speak geek, find a geek. If you cannot find a geek, try and follow along anyway :)

You have been warned.

Custom Scripts

Custom scripts in Worklog Assistant are a set of commands interpreted by your computer to accomplish some goal. The general workflow of a custom script is:

Workog Assistant sets up a bunch of environment variables depending on the task you're trying to accomplish.
Your script is called using the operating system's command interpreter.
If your script returns with a non-zero exit code, Worklog Assistant assumes that the script failed.

As of this writing, there are two extension points to Worklog Assistant:

Menu actions.
Worklog export.

Both of these utilize the same one-way workflow as above. Let's try a simple example where we add a menu action.

Adding Menu Actions

Go to Worklog Assistant's configuration dialog (⌘+, on Mac, Application->Configuration otherwise).
Choose the "Custom Scripts" tab and click "Add". Mine is pictured below:
Select the "New script" entry and change the text in the Description field to "Hello World"
Leave the "Type" as "Context Menu"
Type in the following in the "Script" section:
- Windows: echo Hello World %JIRA_Summary% && exit 1
- Mac/Linux: echo "Hello World ${JIRA_Summary}" && exit 1
- It should now look like the following
Click "Save"

Now when you right-click any issue, you should see a "Custom" entry as shown below:

If you then click on the "Hello World" entry, you should see the following dialog:

And there you have it! You have created a custom menu action. To find out all the variables that are available to you, you can use the following custom script:

Windows: (set | findstr JIRA_) && exit 1
Mac/Linux: (set | grep JIRA_) && exit 1

Let's make use of this information to open a Google search. This example will run only on Mac but you should be able to follow along on Windows and Ubuntu as well.

Change the "Hello World" script to the following:

open "http://www.google.com/search?q=${JIRA_Summary}&sclient=psy&hl=en&noj=1&site=webhp&source=hp"

This script searches Google for the summary of your JIRA issue when clicked! Note that I did not include the "exit 1" because I don't want Worklog Assistant to assume the custom script failed.

In the next part, I'll talk about utilizing the same custom scripts workflow to export your JIRA time tracking information.

Update: For convenience, I've included the main environment variables below along with sample output.

JIRA_Assignee=sohail

JIRA_Created='Tue Dec 30 17:56:26 2008'

JIRA_Description=-

JIRA_Due_date=

JIRA_Global_Rank=46

JIRA_ID=10124

JIRA_Key=TRACKER-51

JIRA_Original_estimate=0m

JIRA_Priority=Major

JIRA_Project=TRACKER

JIRA_Remaining_estimate=0m

JIRA_Reporter=sohail

JIRA_Resolution=

JIRA_Status='In Progress'

JIRA_Summary=Blogging

JIRA_Time_spent='36h 50m'

JIRA_Type=Task

JIRA_Updated='Sun Sep 4 15:39:52 2011'

JIRA_Votes=0

Guest post on Atlassian

noreply@blogger.com (Sohail Somani) — Sun, 31 Jul 2011 23:08:00 +0000

Readers of this blog may be interested in a guest post I made on the Atlassian blog. It was great working with the Atlassian team (thanks to Alex and Kyle especially) and I hope we can work together again!

I was also very happy that we did not have to send Microsoft Word documents back and forth.

Is Atlassian becoming an Open Source company?

noreply@blogger.com (Sohail Somani) — Mon, 25 Apr 2011 00:29:00 +0000

[There is an update, see end of post]

Short answer: No, but read on :)

I've been playing with the latest Atlassian Plugin SDK and I was finding the tutorials lacking in something I wanted to do.

So I looked at the JIRA source to see how they did something similar. Yep, you read that right: I looked into the source of the crown jewels of of a multi-million dollar software company

How is this possible?

Use the source, Luke.

A couple of years back, JIRA used to come in multiple editions of which only one, the enterprise edition, allowed you to view and compile the source code. Now, there is only one edition and it includes the source code.

Essentially, for $10, you now have access to the source code for JIRA. Now, it is not entirely open source in that you cannot redistribute it yourself, but it is something that helps their users which is a major stated goal of open source software.

Why would they do this?

Redhat is a billion dollar (almost) company and they sell open source software. IBM sells consulting services related to open source software. Microsoft is coming into the fold, kicking and screaming, perhaps throwing chairs, but I modify some of their open source stuff.

In short: keeping the source code for JIRA completely proprietary is probably not that important for these guys. Controlling the distribution and trademark is, however. You can see that with Redhat vs CentOS as well.

Why does this matter?

Instead of giving up and/or cursing the tutorials, I was able to solve the problem on my own. This means a healthier ecosystem for JIRA as more people will become familiar with how things work rather than waiting for a tutorial on "how to do X with the JIRA SDK".

So hats off to the Atlassian guys for taking a well-calculated risk that not many other companies would try.

Back to playing with the SDK.

Update: I took a look at the source license and it's not clear to me whether you can learn from the source code to use in plugins so just be aware that this may not be a kosher way to go.

Update 2: Jonathan, from Atlassian, has confirmed that it is fine to use the source code in this manner. Thanks Jonathan!

New release - Worklog export - 1.0.1784

noreply@blogger.com (Sohail Somani) — Tue, 22 Mar 2011 02:37:00 +0000

This release features a "Worklog Export" feature along with other changes. There are two ways to export your JIRA worklogs:

Use the built-in HTML export
Write a custom script

You might want to use the HTML export if you need to send it to someone else. Alternatively, you could use the custom script capability

You can find the export in the "Timesheet" tab in the drop-down button:

Custom export scripts can be added in the configuration as shown here:

There are a few more functional changes, check the release notes for those.

Happy time tracking and have a good week!

Video: JIRA with an IT Consultant

noreply@blogger.com (Sohail Somani) — Fri, 11 Feb 2011 16:33:00 +0000

Gregory Kneller, whom I have enjoyed working with on various things regarding JIRA time tracking with Worklog Assistant, presented a case-study with Atlassian about using JIRA for solving general business problems.

Among the things considered:

Sharing documents
Time tracking
Dashboards

One of the things I found most interesting was how Gregory managed to make JIRA match the nomenclature of the domain in which he was working. For example, "Issues" became "Projects". Another very interesting aspect was his presentation of worklogs as a "ship log" or a kind of journal. I also use worklogs in the same manner and I'm happy to see that others do as well!

I'm not sure if the slides are available for a quick review, but I'd recommend even a quick run-through of the video. You might get some new ideas.

New release (1.0.1722) - Timesheet and worklog report

noreply@blogger.com (Sohail Somani) — Tue, 07 Dec 2010 15:50:00 +0000

I'm very excited to announce a new release of Worklog Assistant. This new release features a JIRA worklog and timesheet report built into the app. See the video below for a demonstration. The timesheet answers the question: what the heck did I do this week?

Why is this useful?

Keeping tabs on your own activity is useful because it helps you realize how much of your time has been spent on your core job activities. If you feel that you are spending too much time on unimportant activities or your job description is changing, you now have some proof to ask for that raise. You can't improve what you don't measure, which is something I try to live by.

There are also a few other changes so be sure to see the release notes. If you find that something could be more efficient or obvious, please let me know.

Thanks for your time and have a good week!

New release (1.0.1586) - Working offline is easy peasy

noreply@blogger.com (Sohail Somani) — Tue, 26 Oct 2010 13:50:00 +0000

This new release includes the ability to work offline using an issue cache. At the moment, you can switch filters and log work. To work offline, simply click the "Use cache" checkbox in the top-right of the screen:

If you do this, you will be asked to synchronize filters. If you choose not to synchronize all filters, then a cache built up while you were working will be used. This is usually enough.

While you are working offline, all the JIRA worklogs will be collected in the "Pending Worklogs" tab so remember to submit them once you are back online!

In addition to these changes, Worklog Assistant now supports Ubuntu 10.04 LTS as the base. Support for 8.04 LTS has been dropped.

Check out the release notes for more.

Thanks for your time!

Custom scripts: that's freaking awesome!

noreply@blogger.com (Sohail Somani) — Thu, 21 Oct 2010 15:55:00 +0000

When I initially put out the custom scripts feature in the latest release (documentation), I was a bit worried that no one would be able to see it being useful. No one had asked for it except me! Upon release, I got some very good feedback but nothing that made me too confident.

Today I was pleasantly surprised. Doing the usual customer support rounds, I came across a feature request from "t" which was a bit particular to his/her requirements: the ability to copy a specific JIRA field to the clipboard. I usually try and keep from implementing such specific requests because it clutters the application.

So the first thing I suggested, just because I thought t's workflow was similar to mine, was to do what I did and use custom scripts to do all the checking in/out of source control.

S/he had other things in mind:

sudo apt-get install xclip

and than:

echo $JIRA_Key | xclip

perfect!!! thx

Just to clarify, t realized that s/he could install xclip (the first line) and use a custom script to copy it to the clipboard using xclip (the third line). I could only think of one response:

Haha, that's freaking awesome!

When I added custom scripts, I really wanted to empower the users to do stuff that I wouldn't or couldn't for whatever reason. I'm glad to see that promise fulfilled in this little way. Great job "t"!

New release (1.0.1531) - improve efficiency by customizing

noreply@blogger.com (Sohail Somani) — Tue, 12 Oct 2010 04:43:00 +0000

This new release has a few new features and improvements. One is an improved update experience which has been a long time coming! There are also some JIRA worklog and time tracking-related improvements. You can find more in the release notes linked above.

The biggest, something I've been itching for myself, is the capability to extend Worklog Assistant by adding your own custom commands. In a nutshell, you can attach and execute a shell script against any JIRA issue and Worklog Assistant passes down the issue fields as environment variables. For example, the key is passed down as the "JIRA_Key" environment variable. Custom fields are also passed down and spaces are replaced with underscores.

You can see an example of a custom script I use in the screenshot below (configuration dialog is pictured):

This script optionally creates and switches to a new branch. You can also see the custom scripts in the context menu for the selected issue (right-click on selected issue):

This is useful for me because I usually create a new branch for each issue. This extension makes it more likely that I will keep up that very good practice.

Like it? Hate it? You can send me feedback about this or other things, I'm always happy to hear it.

Happy time tracking and have a good week!

New YouTube Video Channel

noreply@blogger.com (Sohail Somani) — Mon, 11 Oct 2010 20:48:00 +0000

I've created a new YouTube Channel for Worklog Assistant videos. I'm planning to add a lot more once I get the hang of it. I figure each new feature/behaviour could do with an explanatory video. I think I have some catching up to do ;-)

There is already one video available demonstrating the "Custom Script" feature which makes Worklog Assistant a little more flexible by allowing you to write lightweight command extensions. The feature is still in beta but feel free to view it and comment if you like. You can also feel free to download the beta and try it out. I'd love to hear from you if you do.

Check it out and subscribe! http://youtube.com/worklogassistant

Improving customer satisfaction by time tracking? Yes!

noreply@blogger.com (Sohail Somani) — Tue, 10 Aug 2010 13:44:00 +0000

JIRA time tracking allows you to log work against issues. In fact, many issue tracking systems now support logging work against issues with varying degrees of functionality, but my happiest experience is with JIRA. My product, Worklog Assistant, is a hassle-free time tracker for JIRA so this is a topic near to my heart.

Why would you want to measure and manage your time? The most fundamental reason as an organization is to improve whatever service it is you deliver. For example, if you are a consultancy, you want to make sure the best and highest margin consultants have as many billable hours as possible. If you are a software development organization, you want to be sure that your star developers are not mired in meetings or spending too much time working on legacy components. As a support organization, you need to know which customers are using the most support hours so you can sign them up for the Platinum support contract.

But most people really hate time tracking. I still do, believe it or not. It is notoriously difficult to track your time without the help of a robot.

So what service do I deliver? Is it a time tracking application for JIRA? Not exactly. I deliver something that makes it easy to track your time directly in JIRA. A subtle difference! If something is possible but annoying, it's still not going to get done properly. Some anecdotal evidence from my testimonials page:

I'm happy to report that the logged hours across my team doubled since we started using your tool. They're also much more accurate since the tool is completely objective.

Here is another one that just came in as I was typing this blog post [Note: This blog post was written in January]:

Your product has made my daily management considerably easier.

Exactly my goal. Thank you dear users!

At the end of last year, I felt it was important to review what I could do to serve my current and future customers better. I believe one of the ways that I can serve them better is by spending as little time as possible doing administrative things because that keeps me from improving the product. Administrative work is usually never completed, only obsoleted. I made it a point to record tasks like manual testing, planning new releases and building new releases. I turned to JIRA's new query language to help me decide what was taking the most time:

And man, was I surprised:

The above image shows that making new releases took 3 full days out of the whole year. That is 3 days I do not fix bugs, add features or talk with customers. To put this in perspective, I spend up to one week a month on Worklog Assistant. So nearly 10% of the time I spent developing Worklog Assistant was put into making new releases. Completely unacceptable. All the other tasks above were one-time jobs. That is, once the work was done, I usually did not need to revisit that task.

The question, to me, was obvious: how can I modify my process to reduce or eliminate the time I spent making releases? I reviewed the process for making a release:

Merge development into main line
Build the software: manually check out on Windows and Linux VMs and execute build and test scripts. Do the same on Mac build machine.
Wait for about an hour.
Fix any issues.
Repeat until no more build issues.
Generate updated website and upload all build artifacts
Make release announcements

Believe me when I tell you that I am completely embarrassed by the above procedure. Although I never made a mistake, it was quite easy to do by checking out the wrong branch or forgetting to update the working tree. Building and uploading artifacts was all automated, but I had to manually start and babysit the process. That was what ate up the most time!

The solution is probably obvious by now: I needed some build machines.

Fortunately, buying some good build machines was within the budget. So as soon as they got here, I set them up immediately using TeamCity. I wondered how long it took:

The above image shows that setting up the build machines took me around four days. Hmm, oops? Not quite! Remember, this is a one time investment and I just had really bad luck with installing Ubuntu (had to do it twice with two different versions to get some VMs to work.)

Compare the old process above for making an official release compared to the new process:

Merge into main line of development
Make release announcements

As some of you may know, I have an active beta program. You may also be actively using the beta. If there is a bug fix or experimental feature, I need to get these out as soon as possible to the people who are most interested. And believe me, if there is a bug fix, I want to get it out to the user yesterday!

Perhaps unsurprisingly, I rarely made beta releases last year because it just took too long. Not anymore. Here is my new process:

Merge feature or bug fix into beta branch

That's it.

In January of this year alone, I've been able to make more beta releases than I was able to in 2009 altogether. And I can tell you that the users are happy.

They are happy because I can prove that I am paying attention. They are happy because they can give me feedback on improvements they can touch.

In the same month, I had a relative torrent of really great comments and feedback in my inbox directly related to the support I am able to provide thanks to the beta, which was previously languishing. I know I've made the right decision.

You can't improve what you don't measure.

How true! So how did time tracking with JIRA help me serve my customers better? Simple:

Tracked all my tasks in Worklog Assistant
Found the least efficient task using JQL: babysitting builds
Purchased and configured build machines: no more need to babysit builds!
Reduced average time required for a release to 5 minutes down from an hour: more frequent beta releases with bug fixes and new features
Customers like being able to use features and fixes as soon as possible: happy customers!

I had no idea I could improve customer satisfaction just by time tracking. What can you improve by tracking your time in JIRA?

New release (1.0.1387)

noreply@blogger.com (Sohail Somani) — Mon, 14 Jun 2010 03:31:00 +0000

A new release is available. From the last release announcement on this blog (for 1.0.1355), there are some minor improvements which you will probably not notice but I hope you are inexplicably a little happier when using Worklog Assistant. I know I am!

One you may notice is that the time tracker for a JIRA issue is now automatically started when you start the progress and progress is automatically started when you start the timer.

In addition, there are a few bug fixes that probably won't affect most people but annoyed the people who found them:

Automatic JIRA worklog rounding is delayed until submission time
"Unknown error" caused by JIRA's version of Axis sending different types
JIRA worklog entry window no longer discards incorrect data

Big thanks to the reporters for helping me debug the "Unknown error" in particular.

Keep 'em coming.

Well, that's all for now. Have a good week!

Update: A new version has been released due to a bug affecting certain workflows with the auto-timer/progress starting.

New release and JIRA 4.1 support (1.0.1355)

noreply@blogger.com (Sohail Somani) — Sun, 02 May 2010 18:50:00 +0000

This release is mainly a bug fix and user experience tweak release. It includes a bug fix for updating on Ubuntu so it is recommended for Ubuntu users to upgrade. The remaining are UX related.

In general, JIRA 4.1 is now officially supported. You may also experience better network performance.

Have a good week!

Atlassian's security breach

noreply@blogger.com (Sohail Somani) — Tue, 13 Apr 2010 19:05:00 +0000

Yesterday, there was a notice of a security breach at Atlassian resulting in the theft of some passwords. There were a number of things that combined to cause this problem and we are promised more details. I applaud Atlassian for having the guts to be open about the whole thing. I must say I thought it was a phishing attempt from the get-go.

The best thing for you to do in a case like this, whether you were affected or not, is to re-evaluate how you manage your passwords online. If you fall into any of these categories, you were likely running around changing passwords like mad:

You have one password for all websites
You have one password for all business websites and another for all social websites
You have one password for X class of websites, another for Y, another for Z, and so on

There is one more step you can take: LastPass

LastPass is quite literally the last password you will ever choose to remember. It uses a single passphrase + client-side encryption to store your passwords and can generate random secure passwords for all the sites you use. That means that you can potentially have a different password for every website you use without having to remember each one.

Is it ultimately secure? No, nothing ever is. But because of the techniques used, even if all their database was belong to some h4ckrz, it should be very difficult to break the encryption.

However, it does mean that the "last" password you use must be incredibly secure. Really secure. Unguessable by brute force or even by your closest relations.

So if you were caught in yesterday's email bomb, you may want to consider it. I do wish LastPass was Open Source so that the security could be verified, but you can verify most of the client side stuff yourself.

Disclaimer: I'm a random dude on the Internet so do your own research :)

New release (1.0.1339): Worklog rounding!

noreply@blogger.com (Sohail Somani) — Sun, 28 Mar 2010 18:33:00 +0000

A new release of Worklog Assistant is available:

This update includes a new feature: worklog rounding. Typically, when you log work in JIRA, Worklog Assistant is as accurate as possible, to the second. This results in reports containing odd numbers like 5.833 h which inevitably end up as odd dollar amounts. However, in some situations, you may not want this behaviour.

For example, due to some contractual issue, you may instead want to log 6 hours. Conversely, if the above was 5.45 h, you may instead want to log 5 hours. A "banker's rounding" for time tracking, if you will.

The main control for this functionality is pictured below (found in the "Pending worklogs" tab). I'm not quite sure if the wording helps or hinders, but please let me know either way! As you can also tell, Worklog Assistant will now consolidate all your pending worklogs for a given issue into one. This means that you can apply the rounding to the sum of your pending worklogs, rather than individually, which is probably much closer to what you want.

In any case, I hope you find this new functionality useful. You can find more information in the documentation.

Happy time tracking and have a good week!

An easy way to get more feedback: Shout!

noreply@blogger.com (Sohail Somani) — Thu, 04 Mar 2010 19:00:00 +0000

User feedback is critical to making your application better. I absolutely crave feedback from users. However, it is probably also one of the trickiest things to accomplish. Feedback helps me guide new features and heavily informs upcoming versions.

My application, Worklog Assistant, just helps with JIRA time tracking. In the big picture, it's really quite boring to most people. So if it does the job, most people are content not to say anything. I thought that I should get more people to offer feedback, for better or worse. Maybe there are some obvious things I am missing (hint: there are!)

So, some time in January, I tweeted about an upcoming (very unscientific) experiment. At the time, I did not mention details to anyone. As you can guess, it had something to do with gathering more feedback.

At the top of Worklog Assistant's main screen, there are a few icons as seen below:

The little blue speech bubble has a tooltip which simply said "Send Feedback". Using Thunderbird's filtering capability, let's see how much feedback I got through this button over a seven month period:

That is a grand total of 8. E-i-g-h-t. Wow. According to Google Analytics, that is from a total of about 200 unique visits, for roughly 4% over all of 2009. I repeat: ALL OF 2009! Initially, I thought maybe no one cared (sniffle.) But then I sat back and thought about it from a user's perspective. Do I really want to "send feedback" for any apps that I use? The answer: ABSOLUTELY NOT!

Generally, I want to have a conversation with the authors of the application. And this has been my exact experience when talking to users. So I thought about it for a little bit. Eventually, I settled on changing the blue speech bubble to the following:

Why "Shout!"? I'd like to say this was based on some intuition but basically, I wanted something that people would click on which had some vague relation to its intended purpose and was enough to interest people. I released this change around the end of January and didn't really bother to check into it until a certain someone reminded me. Of course, I tweeted about the "experiment's" success!

Here are the cold hard statistics:

170 unique visits to the target page in ONE MONTH due to this simple change. Compare this to 200 for the whole of 2009 and part of 2010.
Thunderbird says 12 new questions/suggestions as a result, a rate of 7%

The bottom line here seems to be that not only did I get more click-through, but the target page encouraged more people to initiate participation!

But there is another side effect. Some people that had never participated before now started to comment and vote on things they were interested in. So I think I've comfortably got a lower bound for new participation.

Conclusion

There is none. This is not a proper statistical test. But I think there is something there. What do you think?

Nitpicks and clarifications:

But this is not scientific! Yes, I know.
But you don't know whether it was the presence of the text or the value of the text which caused the greater traffic! Actually, yes I do (within the boundaries of being unscientific to begin with.) The first screenshot shown above was preceded by exactly the same icon but with "Send Feedback". Miserable, miserable click through.
But you could have had a 1000-fold increase in customers in that month! Oh, how I wish that were true.
But it could be because February is after January! Yes, you're 100% right. It could be.
But you said all of 2009 and 7 months! You liar! Well, I took a shortcut: The 7 months was the entire time the button was active so technically, I'm not lying.

Well I hope that was interesting for you. It certainly was interesting for me. Big thank you to "dermike" for reminding me to check into my experiment. You made my day.

Feel free to nitpick some more.

Wanted: Brave souls for an experiment

noreply@blogger.com (Sohail Somani) — Mon, 01 Feb 2010 00:31:00 +0000

I am in need of some brave souls who are willing to be part of a small experiment. I suspect most readers of this blog will meet the simple criteria I have for participants which is why I posted here.

The purpose of this experiment is to get an idea of what your work on the computer is like, in terms of context switches and away time. This will be represented in a simple graphical way which you may find useful even after the experiment. You can see an example at the bottom of this post.

All I would require from you is to let the application run in the background and send me a screenshot of the state of the application when you are done your work day. You can do this as often as you like but at least once at the end of your day is requested.

If you are interested, please email me and include:

Your primary job function (web developer, technical documentation, etc)
Your operating system
Whether you currently use JIRA or another project management tool

I look forward to hearing from you!

New release (1.0.1276)

noreply@blogger.com (Sohail Somani) — Sun, 31 Jan 2010 22:34:00 +0000

A new release is available:

This release brings a couple of major bug fixes as well as some minor new features. The rest of this post discusses one of the new features. Your life may be made more complete by reading it.

JIRA's standard workflow is a little something like:

Enter issue
Assign to user
User starts progress
User tracks time against issue
User resolves issue (progress implicitly stopped)
Issue is verified and closed

If you're anything like me, you probably forget to do steps 3 and 4 regularly. Worklog Assistant helps you track your time in JIRA by being an interface you can go to to accomplish 80-90% of the work you need to do with your JIRA tickets. Indeed, if all it did was let you log your time worked, it probably would not be very helpful. Some of the things you can do from the Worklog Assistant interface:

Issue filtering and free text search
Workflow transitions (stop progress, resolve issue, etc)
Commenting on issues
Issue operations (edit, move, etc)

Typically, when you start tracking time against an issue, you are starting progress on the issue. However, JIRA has no mechanism that I know of (besides writing a server-side plugin) to perform the "Start Progress" transition when you log work.

So now, Worklog Assistant will helpfully execute the "Start Progress" transition the first time you log work against an issue. This means you never have to remember steps 3 and 4 again! One less thing to remember makes for happy people and happy people can only be good for your project.

With that, I bid you good day and hope this coming week sees you make a lot of progress!

Now, if only Worklog Assistant could do my work for me...

New release (1.0.1135)

noreply@blogger.com (Sohail Somani) — Mon, 04 Jan 2010 01:36:00 +0000

The first release of the new year is available:

This release includes some bug fixes and a new feature. See the release notes for details on the bug fixes.

Some users and myself noticed that a lot of the time, as soon as we turn off a timer, we published the worklogs to JIRA right away. So my workflow would be a lot like:

Start timer
Do some work
Stop timer
Command-P for publish (or CTRL-P on Windows/Linux)

Now you can click the "Automatically submit worklogs" option in the redesigned configuration window as shown below:

Whenever a worklog is added to the pending worklogs, it is automatically submitted. Any errors that occur are reported to you otherwise you can continue on your work. This is a good way to ensure that you don't forget to submit your worklogs to JIRA. As it turns out, this is a common occurrence. Hopefully this lets you work with a bit more security on that end of things.

Well, that's all for now! Have a good week and happy time tracking :)

New release (1.0.1131) and x64 support for Linux

noreply@blogger.com (Sohail Somani) — Sun, 29 Nov 2009 20:00:00 +0000

Note: I suggest everyone upgrade to this release if possible.

It finally happened. After attempting for as long as possible to have a single deb/tgz for 32 and 64-bit on Linux, I gave in and created a 64-bit package. The main reason for this was that Worklog Assistant now uses gnome-keyring to store passwords on Linux. As gnome-keyring is not part of the ia32-libs package, this meant a 64-bit package was needed.

If you install the PAM module, the keyring will be unlocked on login, otherwise the keyring software will prompt you to enter your keyring password when you launch Worklog Assistant.

So now, time tracking for JIRA just got a little bit better on Linux ;-)

There is also one bug fix due to the recent change to group worklogs by issue in the pending worklogs screen.

Thanks for your time and happy time tracking!

New release (1.0.1128)

noreply@blogger.com (Sohail Somani) — Mon, 16 Nov 2009 02:16:00 +0000

A new release is available. There are two major feature improvements in this release as well as official JIRA 4.0 support! The first being that pending worklogs are now grouped and summarized by issue. This should make it easier to see what you have worked on before submitting.

The next improvement is one of my favourites: on Mac, the dock icon now contains the total of all the pending worklogs as well as the current active task. See the screenshot below:

There are also some minor but useful improvements to the idle time detection. Previously, when you returned from idle, say to check email or the time, Worklog Assistant would pop up and ask you if you wanted to apply the away time to a task. This behaviour has not changed.

However, the dialog would previously assume that if you returned, you were back for good. Now, when you return, you can leave the dialog open and Worklog Assistant will continue to track your away time. When you finally return and accept, the correct away time will be used.

This is very useful for those cases where you are doing a software build, or a run of tests and just come back to check if they are done. From now on, you can just leave the notice open and your away time will continue to be tracked.

JIRA 4.0 support

Thanks to the awesome backward compatibility work by Atlassian, Worklog Assistant always maintained JIRA 4.0 support. However, I can finally say that JIRA 4.0 is now officially supported. This includes the server side plugin as well as the desktop client. As an aside, I have officially switched to using JIRA 4.0 internally and it is at least 100 times better than JIRA 4.0. My favourite "new" features:

Dashboard - Awesome!
Activity stream - What issue did I just change?
Greenhopper!

I used Greenhopper to manage this release and I must say I am never going back to the old way of bulk filter changes.

Last but not least, there is now a new "thin" installer for Linux. Basically, you untar+gunzip and you are ready to go. This should help on non-Ubuntu platforms.

I hope you find these new changes to be useful, I know I have. If you find any issues, please let me know.

Happy time tracking and have a good week!