FeedBurner makes it easy to receive content updates in My Yahoo!, Newsgator, Bloglines, and other news readers.
Learn more about syndication and FeedBurner...
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!
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!
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!
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:
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:
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:
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!




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.
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
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.
[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?
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!
This release features a "Worklog Export" feature along with other changes. There are two ways to export your JIRA worklogs:
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!
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:
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.
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!
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!
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 xclipand than:echo $JIRA_Key | xclipperfect!!! 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"!
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!
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 ;-)