This is a known issue and will be fixed in the next release of The Bug Genie 3.1 – due out after testing.

In the meantime, if you are unable to access your account as you have forgotten your password, please post on the forums or email support@thebuggenie.com, and we will reset your password for you.

First of all, marking topics as solved

A feature that is often on support forums is a ‘mark as solved’ function. When your problem is solved, you can let everyone know what post in the thread solved the issue, and this brings many benefits:

• We know a problem is solved, so we don’t have to come back to your thread, making our life easier
• It’s easier for us to see what problems still need solving, saving us time
• Other people with your problem can jump straight to the solution, saving them time
• You can be satisfied that your problem is all wrapped up and done with, giving you more satisfaction

Threads marked as solved get a little green tick wherever they are shown, and clicking this tick jumps straight to the solution.

We have turned this on in our ‘problem-solving’ forums, though we can always add it to more if necessary.

To mark a thread as solved, just click the little tick. Please note that only you and the moderators/administrators can do this, so please be vigilant. The tick is found near the quote button:

And secondly, logging in with OpenID

Having multiple accounts everywhere is a pain. One of the new features in The Bug Genie 3.2 is OpenID support, and it would be a little contradictory if we supported it on our tracker but not the forums! With this in mind, once the theme is fixed, OpenID support will be added to the login page, so you don’t have to create yet another account to make use of the forums.

This is now available! You can link your existing accounts to an OpenID if you want, go to your user control panel and choose Profile.

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.

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

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)

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).

If you can access the issue tracker and forums again, the move is complete! If no, just wait a little bit for the DNS to update, it may be a bit slow.

The main improvement is everything is a lot faster now, a concern many of you had with our old hosting. In addition to this, the random bursts of inaccessibility should now be gone too. Some more exciting things will be coming soon, too!

If you find anything not working, please do let us know so we can get it all working.

It’s been a really busy last month. As usual when we release beta versions we get a lot of feedback, so apologies to anyone that hasn’t received an answer yet. The next beta (beta 3) of the upcoming 3.2 version has been a bit delayed since we wanted to finish a significant upgrade in our backend code, namely moving to an updated version of our database layer. Now that this has been completed, and the development version is almost 100% back up and running, we’re working hard to get beta 3 out the door.

We’ve traditionally done one new point-release every 6 months and service releases (.x.x) about every month or so. We’re still on target for a 3.2 release approx. 6 months after the 3.1 release, but the current beta release has set us back about a month from the originally estimated date. With a small team like ours, delays are inevitable, but we really are working hard getting this release finished and ready. 3.2 is such an enormous improvement over 3.1 that we really don’t want to hold it back any more than we absolutely have to!

How can you help?

• Fork us. Fork us on github, send patches back as merge requests or ask to be more involved with the team
• Create translations. Translations are very simple to do, and requires no programmer knowledge.
• Share your own patches and tips
• Donate. Money.

Hopefully a new beta can be released before the end of this week, but please bear in mind that we have day jobs, too

Cheers!

Here’s a short list of the beta 2 highlights:

Improved search tools

We’ve finished the search layout rewrite, which have lead to a much better search experience. The search builder has been simplified and reorganized so it now makes more sense than it did in beta 1:

You will notice that the text filter is now part of the main filter list. In addition to this, we’ve moved the template, issues per page and grouping details to “More search details”, as this is not something you’ll be changing especially often.

We’ve also added several new search features:

“posted by” (user), “assigned to” (user or team) and “owned by” (user or team) filters lets you search for users related to issues, and have been long missing in our 3.x release.

“posted at” and “last updated at” (date searches) filters lets you search for issues posted/updated before or after a specific date, or within/outside a specific timeframe.

Two new predefined project searches: “Issues posted this month” and “Issues posted last 30 days”. The last of those two lets you specify a custom number of days, but defaults to 30.

Sidebar autohiding – when you search, the sidebar is automatically hidden so you can see more search details. After all, that’s probably what you’re looking for, isn’t it?

Improved issue details

We’ve moved all buttons scattered around the issue detail interface into the new “More actions” menu that is available in the top right corner at all times. This includes adding related issues, posting links and files, and more.

Bugfixes and tweaks

A lot of bugs have been fixed, including bugs in the installer, upgrader and elsewhere in the system. After beta 2, we will focus mostly on fixing already reported bugs, so keep them coming!

One of our users posted up a performance analysis earlier today (http://www.synet.sk/php/en/890-tbg-the-buggenie-issue-tracker-performance-analyze), where some of the points made much sense and were items that were long overdue for improvements. Some of the points brought up won’t be addressed for various reasons, but there were also some that we immediately fixed:

Poor B2DB cache performance

As was thoroughly explained in the analysis, the b2db cache performance was far, far from optimal – in many cases the disk I/O can cause significant strain on the system. Further analysis on our own part also revealed even more problems with the existing cache implementation, leading to an immediate rewrite of the caching system. The existing b2db cache would actually re-read the cache files every time a cached property was being accessed, and the caching would only happen “on-demand”, leading to random caching, heavy I/O operations and relatively poor performance (for a cache).

We rewrote the cache so we now generate a complete class cache whenever the class is being accessed for the first time. This class cache is saved to disk and only read once per request for later requests. In addition, we don’t do a full backwrite of the entire cache on each request. Total win. Next!

Loading external resources

The amount of resources loaded from external servers, as well as the potential problems when loading files from external locations (corporate setups) was also brought up as an issue in the analysis. To address the issues mentioned, we’ve moved from loading the custom fonts from googles servers to hosting them inside The Bug Genie (this is also reflected in updated licensing information). This will both lead to improved loading times and less reliance on external resources.

Gravatars can be turned off in system settings, so that point will not be addressed.

GeSHi loading causes slowdowns

The way GeSHi (the syntax highlighting library) is being loaded causes unnecessary waiting and loading time. This has been rewritten so it’s now only loaded on demand, and loaded lighter than before. Win!

Inconsistent measuring of execution time

The way we render and generate the log items in <=3.2 beta1 makes the log less useful for actual timing analysis than for a general impression of how long it takes to render a complete page, as well as providing important inside information on execution. However, because the log and debug information needs to be generated and rendered early in the execution stack, we miss out on things going on after the page is rendered, and that can often mean that the log is incomplete and can appear to have “holes”. We’ve completely rewritten the way we generate and present the debug and log information so it is now loaded dynamically after the page has rendered completely. In addition to this, we can now load debug information for any ajax request made on the page after it has been loaded, providing even better profiling and debugging tools for module developers as well as users looking for insight into how The Bug Genie works.

Please keep in mind that this is a debugging tool for The Bug Genie development and it is not supposed to be a precision tool for profiling or timing information. However, we always want our tools to produce accurate information and be valuable. Again, win!

Other points

We’ve improved database indexes, and will continue to improve them even more in the future, after our database layer gained improved indexing features very recently. We’ll continue to improve caching and general performance as this is really important to us.

Points that will not be addressed

PHP 5.2-compatibility – This is an item that is brought up repeatedly (although less now than before). We will not make The Bug Genie php 5.2-compatible. PHP 5.2 is old, insecure and performs far worse than php 5.3. Please – update your servers.

PCRE 7.x-compatibility – Same as above, we will not make an effort to support PCRE 7.x. PCRE 8.0 was released October, 2009, and can hardly be called “new”. We realize that there are problems with this library on CentOS and RHEL-installations, but even when running these older server OSes, virtualization is still an option.”

We very much appreciate detailed reports like this – it is really valuable to us. We’re a small team with very limited resources, so all help is appreciated.

Thanks!

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!