Our apologies to those wishing to use the mercurial hook who have been unable to find it. We have restored the hook, and it is now available again by clicking Modules Library in the footer.
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).
We’re about half-way through the 3.2 development cycle, and it’s starting to become apparent what kind of changes you can expect from the upcoming release. We’ve settled on quite a few features to be included, and even though several of these features haven’t seen any development yet, we’re excited to share with you some of the already completed features and changes. Here are a few highlights of what have been going on in the 3.2 development branch the last few months:
- Project dashboard reorganization
We love our project dashboard and project-sections, but there is huge room for improvements. The 3.2 version has seen and is continuously seeing huge improvements and drastic changes in these areas. The main dashboard has already gotten a big facelift, and some of the new functionality we’re working on will have a much more prominent place in this new layout. We don’t want to give it all away just yet, so expect more news related to this 😉
- Focusing on your projects
The projects are receiving a lot of love these days. We’re including functionality to better manage your project setup (editions and components); we’ve added support for subprojects to better organize your existing projects; we’re adding much improved release functionality and redesigning the way editions, components and releases work. Project permissions have largely been fixed in our latest releases, but we still have a thorough inspection and fixup planned for project permissions to behave in an expected way and maybe even reduce the complexity.
- Search improvements
The main search has also seen some new functionality. You can now sort on the table headers in search results, and you can show / hide columns in the search results to better find the information you need. Also to come is bulk editing functionality, as well as a few other treats.
The list above is far from extensive and far, far from a complete list of changes gone into the 3.2 release. And we still have a lot of stuff on our plates – incoming email support, fully functional LDAP authentication support, support for HTTP auth, bulk editing (as mentioned above), file upload and download functionality for projects and a lot more.
As always, we’re constantly looking for people willing to contribute to the bug genie on a regular or random basis. If you’re familiar with php, html/css or UI / UX design, don’t hesitate to get in touch!
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. Continue reading “Try out LDAP!”
Following my previous post, all the proposed changes to VCS Integration have been made, and this means some important changes for you upon the release of The Bug Genie 3.2:
- Upon upgrading, the module will be disabled until you upgrade its database from module config. This will be made clear to you, in the mean time commits can’t be checked in.
- Your hooks will need reconfiguring. We are now using the project key instead of the project ID, so minor changes to your hooks will be necessary. This is simply a matter of replacing a number with a word, project keys are visible in the projects list in configuration. As a note to those who want to try out the latest code from next, due to an unrelated issue, the direct access method (via tbg_cli) still uses ID-based access, even though it says to use the key.
The upgrade process is necessary due to various database changes we have made. The script will import all your old commits, and set the new settings so that they match the previous configuration. You can, afterwards, go through and alter the projects to take advantage of the new features – such as different access methods for different projects.
The script will import all projects which had VCS Integration enabled beforehand to have it on for issue-affecting commits only, all with the same access method and (if using the HTTP method), the same passkey. The URLs for each project will be imported from the old settings.
Testers wanted! If you want to give this a try, feel free to check out the next branch from github and give it a go! There are probably some loose-ends to tie, so please let us know if you find any problems.
What else is new? Naturally, quite a few problems were found in the main code, which were fixed. One of most note to those of you who use the inbuilt scrum support was a bug where anyone can change the scrum colours. This has now been fixed, and only those who have permission to edit issues can have this magical power.
For the next release of The Bug Genie 3, there will be some exciting improvements to the VCS Integration module. Here is a taste of what is up to come!
Improved setup and configuration
Setting up the module is a bit confusing at the moment, with project IDs being used which aren’t really visible, as well as it not being clear where the projects are set up. We will be moving the project-specific parts of VCS Integration to project configuration, allowing the access method and passkey to be set on a per-project basis, as well as improving the configuration so that it is a lot clear what you need to do after typing in the boxes.
Better support for repository browsers
Setting up a repository browser is a bit confusing at the moment, with details split over three boxes, some of which don’t apply in all cases. We will be merging all the boxes into one for each kind of page to be viewed (index page, diff page etc.), with %placeholders% so that it is easier to set up the URLs. This also means that The Bug Genie will support any repository browser under the sun, as long as the fields are inputted correctly.
A lot of users have requested that it should be possible to localise the words which The Bug Genie picks up. The pick-up words will now be user customisable, as well as supporting cases where no word is wanted at all. Picking up of issue mentions will become better too thanks to some new API functions.
Not just commits that apply to issues!
VCS Integration will also (optionally) pick up ALL commits. This means on the project commits page, you can see a list of all commits ever made to the repository (since setting up). This isn’t quite inbuilt repository browsing, but it will help with keeping track of things. This will also mean database changes, but an added bonus is users of Gitorious will be able to have commit boxes displayed on their issue, as data will no longer be stored in the database on the basis of file changes – instead commits.
Hopefully this should give you a taste of what is to come. Along with fixing any bugs (there is one with Git we are meaning to look at), this should help improve this slightly unloved feature of The Bug Genie. Thanks to all who have suggested improvements!
Just a little quick note to let you know that we’ve decided to postpone the release of the LDAP authentication module. With a small team of developers, we simply don’t have the manpower to get it finished, and 3.1 needs to be released 😉 We’re still leaving all the work done on the authentication backend in with the 3.1 release – and as soon as the LDAP module is finished, it will be released on our plugins section.
Look out for an RC soon!
Edit: LDAP is taking a little longer than we were expecting, but we want to get it done right and proper. Therefore we have decided to release Beta 2 without functioning LDAP support. The interface is there so you can see how it looks, but do not set your authentication method to LDAP as you will be locked out. When we have a functioning addon, we will let you know here on the blog!
As mentioned in a previous post, thanks to the hard work of crazedfred and xaver in the Live Chat service, we are currently implementing support for authentication against LDAP (which includes Microsoft Active Directory). The reason we have delayed Beta 2 is because we really want to have something you can play with in the LDAP department, and within a day or two we will have support for logging in implemented. Continue reading “New in 3.1: LDAP Authentication”
Hi again 🙂
The last two weeks have been filled with exciting activity in our development branch. Several users have stuck with us to provide us with excellent feedback, which have made us put some extra effort into the second beta release. We don’t want to rush it, as beta 1 was just too unstable for our liking, with several bugs in basic functionality that should’ve been uncovered before the beta 1 release.
In addition to doing a ton of bugfixing on the existing code – much more that we would have imagined from our initial beta 1 release – we’ve also squeezed in several new features. This makes the 3.1 release shape up to be a much bigger feature release than initially intended. This isn’t the reason the next beta have been delayed – some of the bugs we’ve fixed have been quite persistent and hard to track down, so instead of doing nothing while waiting for other team members to land bugfixes, the rest of the team have been hard at work adding stuff instead.
New, improved or added since beta 1 is:
- LDAP authentication backend
The Bug Genie has always supported alternate authentication backend via its plugin architecture. Version 3.1 now ships with a working LDAP authentication plugin to provide you with both an example implementation of an alternate backend for authentication and also added functionality! More details about this plugin in a separate blog post.
- Much improved multi-platform support
The Bug Genie supports several server platforms by default, including other web server platforms like nginx, as well as database backends such as postgresql and mysql. Version 3.1 has seen much improved support for both nginx (via improved documentation) and postgres with several bugfixes for common scenarios.
- Wiki search
We’ve also added wiki search functionality. This lets you search for wiki articles both via the quicksearch field, the wiki menu dropdown, and a separate wiki searchpage. This will give you a lot more overview and control over your project (and global) wiki, and is the first step towards greatly improving the wiki functionality.
- MarkItUp for improved wiki editing usability
We added MarkItUp – a visual editor addition to writing wiki pages. It gives you shortcuts and buttons to highlight and format text, add links, etc – but does not give you a WYSIWYG editor. Instead, you will learn the syntax in use by The Bug Genie as the MarkItUp editor provides quick shortcuts for The Bug Genie’s MediaWiki-compatible wiki syntax.
There’s quite a few more minor (and major?) features in there between beta 1 and beta 2, and we’re excited for you to find them all. 3.1 will be our best release ever, and we can’t wait for you to join in on the fun.
The next beta release will be available this Monday (2nd May), delayed two days from the updated release plan (originally scheduled for 30th April). We’re sorry for this minor delay, but rest assured the time has been well spent.
The Bug Genie 3 supports linking the tracker with your github projects, so you can update your issues in The Bug Genie from your github commits. This feature is ready to roll, but we really need it testing before we release, and this is where you come in!
If you would like to test out this great feature, please do and let us know about any issues you experience in your testing. This is how:
- Install The Bug Genie 3 from trunk. (beta 3 will not work)
- Create a project and some issues in it (for testing, remember their issue numbers!)
- Go to the VCS integration configuration page, and choose HTTP mode. You will also need to set a passkey for http access (NOTE: If you use The Bug Genie with other VCS systems, using the direct access method, these will need to be reconfigured to use HTTP access).
- Set the repository type for your project to Github, and enter anything in the URL box. Then enter your project name into the final box.
- In your Github project, set a post-receive hook to point to http://www.your-tbg-installation.com/vcs_integration/report/PROJECTID/github/?passkey=YOURPASSKEY, replacing the hostname, path and passkey as appropriate. The project ID can be found on the project tab of VCS Integration configuration.
- Now you can try it out, using the exact same commit format as normal commits.
If you encounter issues or need help, just drop a line on the bugtracker or the forum and I will give you a hand. Also, please refer to the inbuilt wiki for further details.
Thank you for your help!