Archive for the ‘The Bug Genie 3.1’ Category
No, we haven’t forgotten about you! We just put out a new bug fix release of The Bug Genie 3.1, which features a number of bug fixes and fixes for the permissions system. Thank you to Daniel Scharrer for his help with fixing a number of issues within the mailing module.
To get this release, just head over to our (still new and shiny) download page!
- The ‘canvoteonissues’ permission is now obeyed
- Guests are now never able to vote on issues
- Permissions are now obeyed when adding a task or adding a relation to an issue
- The php version number is now never included in X-Mailer
- Fixes issue #1091 – Error logging into tracker
- Fixes issue #1047 – Link to User Guide is broken
- VCS Integration now supports scopes properly
- Links and passwords are now set correctly in forgotten password emails
- A number of issues regarding email addresses have now been resolved
- All URLs to thebuggenie.com have now been updated
I’d like to personally apologise on the length of time to get this update out! Future releases will not be delayed as badly as this.
Remember to report bugs to our issue tracker, and if you need any help or have any questions, just ask on the forums!
In the latest version of The Bug Genie 3.1, there is a bug with the password recovery feature – emails are set without the password provided. This affects our tracker and any installations you have.
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 email@example.com, and we will reset your password for you.
Back when we were developing The Bug Genie 3.1, we promised LDAP support. Sadly we were not able to include it with the final release of 3.1, but the good news is that a testing version of The Bug Genie 3 is now out, with LDAP support included. This is release number 3.1.4, and a beta is available to download today, though we recommend you read the release announcement first (download link included).
On top of LDAP support, this fixed a few other issues with the mailing module (looking at you, guys who wanted delayed mailing!), as well as a few regressions from 3.1.3.
Read on for some important notes and some preliminary documentation. Read the rest of this entry »
As a small heads up for those of you who don’t use Apache, I’d like to bring your attention to our library of rewrite rules. We are often asked by users for help setting up URL Rewriting (which The Bug Genie 3 requires) with their server, and this post is there to point out what documentation we have.
Just right now, documentation for IIS 7 and later was added, meaning we now cover the most popular platforms. However are work is not yet done,
with documentation for IIS 6 still unwritten (IIS 6 docs now out!), and apparently issues with the nginx one; on top of no doubt other servers that you wonderful users want to use The Bug Genie on (let us know if there is one you need!) Regardless, we currently support:
- Apache (auto-generated by the installer)
- IIS 6 (Windows Server 2003 and 2003 R2)
- IIS 7 and later (so Vista/WS2008 and Windows 7/WS2008R2)
Further documentation, as well as the above (except Apache) can always be found in the Recipes section of our documentation.
Following the previous blog post – we have not forgot about 3.1.3! So we avoid any last minute mishaps like we did with 3.1.2, we need to spend a little extra time with some final tests, but it will be out within the next few days. Sorry for the delay!
It seems we missed a little detail with the permissions cleanup starting in 3.1.1. The permissions fixes applied there were meant to make all of.your lives a bit easier, but has instead ended up giving some of you a massive headache. We apologize.
We’re releasing 3.1.3 later this weekend to resolve a permissions issue making installations running in restrictive mode not so restrictive after all. This bug gave project access to people not supposed to see certain projects, and subsequently project wiki and project issue access as well.
This, obviously, can be a bit of a hassle when you’re upgrading to a minor release. We’re a small team, but bugs like this should never occur. For those of you unable to wait for the release, pull in this git commit for the fix: https://github.com/thebuggenie/thebuggenie/commit/9e1e0a5429719ea11f35770373b7fdb362597c32
Let us know if you want to help out making thebuggenie rock even more in the future!
zegenie posted a short while ago regarding encoding trouble with The Bug Genie, especially those of you who use Greek or Russian alphabets. The good news is we have made some progress on this topic!
The root of the problem is to do with how The Bug Genie connects to the database. Each component has different encoding:
- Database: whatever you created it as (probably latin1)
- Tables and columns: UTF-8 (we create them as that)
- The connection itself: could be anything
The last of these is the crux of the problem. On my system (as I am from Britain), the connection is latin1. This is fine for me, as I don’t need any unicode characters. However, for those of you who do, this means that unicode data is inserted into a unicode table, but is converted to something else (such as latin1) in the process.
The net result is that it will look right on the screen, but in the database it is garbage. This is fine up to the point where you start trying to do stuff with it, as there is a potential for problems to occur with JSON and other unicode-specific things, as what is in the database is not unicode (it is infact latin1 or whatever)!
An example of this is to copy some Russian text into both the Title and Issue Description fields. It will appear correctly in the Issue Description but not in the Title (it will claim it is empty).
This is easily fixed by setting the connection to use UTF-8, by placing this call on line 539 of core/B2DB/classes/B2DB.class.php:
self::getDBLink()->query('SET NAMES UTF8');
Now, all unicode data will be stored correctly in the database. However, this now results in another problem!
Any mangled Unicode data stored in the database as latin1 will be outputted as stored in the database (as no conversion is going on). This means that the mangled text in the database will be rendered to the screen. Luckily this is easily resolved by outputting a dump of the database in a latin1 connection, and then reimporting in a utf-8 connection (the nice Unicode output is obtained on the latin1 export, not the mangle that you get if you exported as UTF-8). The following code will do this, but don’t do this unless you put in the above code change:
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
We will be continuing to work on these encoding issues for The Bug Genie 3.2.