The Bug Genie 3.2.7 released

Last week, we released version 3.2.7 (and 3.2.7.1 to hotfix an upgrade and installation issue). This release is a collection of all the development that has happened in the 3.2 version since last release which was almost a year ago.

There’s no need for releases to be this far apart, and we’ll try to not let it happen in the future. In the meantime, in this release you can enjoy:

• Improved speed and stability
• A whole slew of translation improvements
• Support for PHP 5.5
• Support for logging in via Mozilla Persona
• General bugfixes

Until next time!

So, what does it look like – part 3

In the first and the second blog post in this series, we’ve taken a good look at the generic theme changes and how we’ve worked to improve project management in 3.2. This post will highlight many of the changes we’ve made to the actual issue management. Let’s dive right in!

Version 3.2 Release Candidate out!

Finally! After quite the delay since the latest beta (beta 4), we’ve finally released the 3.2 release candidate. The 3.2 release is our best release ever, with so much new and good stuff it’s not even funny. If you haven’t already tried it out, you absolutely should!

Highlights, you say? Too much for a minor blog post, I say! One of the things you’ll notice immediately, though, is that we’ve given the entire application a much more modern and visually appealing look. The underlying database layer is significantly faster and more reliable, caching is enabled, and we’ve added features and fixed bugs in every part of The Bug Genie.

All we can say is – please, pretty please with sugar on top, go download the release candidate now, and help us make it the most stable release so far.

Website refresh

Hey all!

Before we could post the new beta version of our 3.2 release, there were several changes that needed to be made in the website infrastructure to prepare for some of the features we want to add while we polish the beta into a worthy RC. Today we launched the new and polished website, and we hope you find it just as easy to use as before. As you can see, we’ve tried to keep the same structure as before, but also wanted to add more content to several section, such as the new “help” and “community” sections.

Let us know if you find any bugs 🙂

The Bug Genie 3.2 and UTF

As discussed earlier on this blog, changes in The Bug Genie 3.2 to improve our support of Unicode may result in some data being mangled after upgrading to The Bug Genie 3.2 The technical reasons behind this have been explained before, this post is just to give a brief overview on what happens and how to fix it, for those of you upgrading from previous releases.

Do I need this?

If you use PostgreSQL, or are performing a fresh installation, this is not necessary. In addition, this may not be necessary when you upgrade from a prior release, especially if you do not use special characters.

The fix, if necessary, should be applied as soon as possible after upgrading, do not perform the fix before installing the 3.2 files. You may, if you wish, install the 3.2 files, run the upgrade script, and then explore your installation to see if the fix is necessary – if you see mangled characters in any text field then you will need to apply it. Do not adjust any field before applying the fix, as any new special characters will be destroyed.

If there are only a few to correct, you can always do this by hand, but the fixes below are more efficient if there are many issues.

The problem

We did not correctly handle the connection to the database in The Bug Genie 3.0 and 3.1. This meant there were occasional issues with special characters being mangled or lost in various places, such as fields in an issue. The connection opened to the server was not Unicode, and therefore the data was not stored in a Unicode fashion, leading to problems.

In The Bug Genie 3.2, we do create a proper Unicode connection, meaning the mangled data will now be shown as-is. While there were cases previously where the data was correctly shown, by ensuring the problem is resolved properly now, we avoid potential issues in the future.

The solution

There are two solutions available. If necessary, you should apply one before upgrading, but you can always check afterwards to see if a fix is necessary. You can apply the fix after upgrading as long as you do not add any Unicode characters to the database beforehand, as these will be destroyed by the fix.

If you have command line access to the server:

The following commands will resolve the issue. A database dump is made in the non-UTF format we used to use in The Bug Genie, this is then restored in the correct format. The database is recreated also, to ensure it is in UTF format, so please make sure you have the right permissions. We assume a database called thebuggenie, and a user called root. Change these if necessary.

mysqldump -h localhost --user=root -p --default-character-set=latin1 -c --insert-ignore --skip-set-charset -r dump.sql thebuggenie
mysql --user=root -p --execute="DROP DATABASE thebuggenie; CREATE DATABASE thebuggenie CHARACTER SET utf8 COLLATE utf8_general_ci;"
mysql --user=root --max_allowed_packet=16M -p --default-character-set=utf8 thebuggenie < dump.sql


If you don’t have command line access to server, but you do have phpMyAdmin:

You can also apply the fix using phpMyAdmin. The trick is to change the connection collation, which can be done via box on the front page

This should be set to latin1 when taking the database export (leave the file as UTF-8), then set back to utf8_general_ci when recreating the database and importing. The database collation should be set to utf8_general_ci, and this can be set via box to the right of the database name field:

Please remember to dump just the data of the database, and not the structure and data. This can be done by selecting a choice when exporting, you may have to choose an option ‘Custom – display all possible options’ first.

How The Bug Genie 3.2’s upgrader fixes your timestamps

Note: The timezone fixer in the initial release of The Bug Genie 3.2 may not work if you have a huge number of issues and comments, as the process is very intensive. We will be performing further changes in the future, and a CLI task to perform this operation will be in a subsequent release of The Bug Genie 3.2. We therefore do not recommend using this tool if you have over 500 issues.

It’s a well known fact that The Bug Genie’s timezone support doesn’t work right in 3.0 and 3.1. One of the more serious bugs was with how timestamps were stored: they were stored in the timezone of the user who caused the action (i.e. opened the issue), and then adjusted to the timezone of the user viewing the thing which involved at time. Therefore, if you both created and viewed an issue which was opened at 03:00UTC, and your timezone is +3, it would be stored as 06:00, and you would see it opened as 09:00.

The cause of this is fixed in The Bug Genie 3.2, and new timestamps will be stored as UTC, so only your timezone offset is applied. This will fix your timezone problems for new issues, comments and so on, but not for previous ones. This is why the upgrade script gives you the option of fixing your timezones.

How does it work?

The script, if you ask it to, will go through every item in the database which involves a timestamp and will remove the offset coded into the database.

We look at the timezone of the user who caused the action (if he has one set, and it isn’t ‘sys’), and if one can’t be found we use the system timezone instead. Also note, if the guest user made a change, then the system timezone will also be used. If the outcome of this is UTC, then nothing needs to be done as there will be no error.

If, on the other hand, it is not UTC, then some work needs to be done. We can then perform the offset change on that timestamp, and this should in the majority of cases lead to the correct result. The advantage of this way is we catch cases where the user timezone is different to the system timezone.

There may still be some times which are incorrect, for example if either the user or system timezone had ever been something different prior to what it is during the upgrade, or if the user who caused the change cannot be identified (this is the case in the builds and milestones table). There is nothing that can be done in these cases to improve the accuracy, as we are suffering from either a lack of history of timestamp settings or users who performed actions, and so we give the option of disabling this conversion. You can also turn it off if you just want your timestamps left alone.

What will it convert?

Times will be corrected in the following tables:

• articlehistory
• articles
• builds (will be corrected based on system timezone only)
• comments
• editions (will be corrected based on the system timezone only)
• files
• issues (posted, updated and being worked on since times)
• log
• milestones (will be corrected based on system timezone only)
• projects (will be corrected based on the system timezone only)
• vcsintegration

Workflow automation in VCS integration

A much requested feature in VCS integration is the ability to close issues using the commit message. We have (finally) implemented this, but as usual, have decided to go a little bit further. In The Bug Genie 3.2, you will optionally be able to use your commit message to navigate through the issue’s workflow, using only basic syntax.

So how does this work?

You may have noticed that incoming emails allows you to navigate through the workflow. We work in a near identical fashion. The difference is how the message is structured.

In incoming emails, you use a syntax similar to this:

resolve issue
resolution=WONTFIX

This is my comment
---

The workflow steps and parameters are all on separate rows.

In VCS integration, we don’t have this luxury so we compact everything together:

Fixes issue 1 (resolve issue: resolution=WONTFIX)

Simply place the workflow step in brackets, and if there are parameters for the step, just place them after a ‘: ‘ delimiter. You can also have multiple parameters:

Fixes issue 1 (resolve issue: resolution=WONTFIX status=kittens)

You may also wish to perform multiple transitions at once, this can be done by using a ‘, ‘ delimiter after the parameters. You don’t have to supply parameters either:

Fixes issue 1 (confirm issue, resolve issue: resolution=WONTFIX, reopen issue)

If a workflow step fails, or if it doesn’t exist, you won’t be notified; so while there is no risk of a mistyped commit breaking the commit process, you may want to double check to see if your workflow step was applied.

Similarly to incoming emails, the workflow steps are just as they are in the toolbar when viewing an issue, so there is little to learn.

If you are eager to try this out, this feature will be appearing in our github repository later today. It will also be included in 3.2 beta 3, along with a working module (it has been broken as a result of the database changes).

3.2 beta release

Just a little headsup that we are closing in on the first 3.2 beta version. Right now we’re finishing up the upgrade functionality (upgrades can be performed either from 3.0.x or 3.1.x), and adding a bit more spit and polish. We will be fixing a lot of smaller bugs as soon as the final polishing is done for the newest features, and then we’re ready to release.

When we release the 3.2 beta, anything goes. Please report any and all issues you find, whether it is upgrade issues, usage issues, installation issues, or anything else that you can trigger. Do your best – break it, and break it hard.

Just to add even more fun into the mix, we’re also adding experimental support for microsoft sql server in the 3.2 beta. If any of you are running with an ms sql server and want to give us a hand testing it out, please file issues against this as soon as you can.

Oh yeah, you probably want a date, too. October 15th.

Update: A lot of effort was made, trying to finish up the caspar framework refactoring in time for the beta release, but unfortunately it is not possible. Because of this, the beta release is being pushed back two weeks, to October 29th. Thanks for your patience.

Thanks!

More 3.2 improvements

To get you even more excited for the upcoming 3.2 release, we wanted to share a few highlights from all the work being done on the next version. We’ve ripped into so many pieces around the entire system, there is hardly anything left untouched – an exciting and scary feeling for a point release (3.1 -> 3.2). We could just as well have pulled “a Mozilla” and called it 3.5, but for the sake of our own (and your) sanity, 3.2 it is 🙂

So, what are all these highlights, I hear you whisper in the corners. Read on to get a glimpse!

Issue details improvements

One of the main areas of focus for 3.2 is improvements in usability and general appearance. We’ve added some new style elements, and are going through all the different areas of The Bug Genie, applying the new style elements where appropriate. These new style elements go far beyond mere looks, however, and whenever we can, we do a functional review of the area we’re working on and try to find things to improve. One of the latest pages to see some style and usability improvements is the issue details page. This page is usually where you spend most of your time, so anything we can do to help here is time well spent. Here is a summary of the changes we’ve made to this page.