Skip to content


mtrack repo ACLs

Updated: Added schema and UI for Projects to own repos and manage groups.

Following through on user repos and SSH, I revised the ACL support in mtrack and added a permissions editor for the repo editing screen. When you create a repo, it defaults to granting you (the creator) full access and denying everybody else access (equivalent to a private repo in services like Github and Bitbucket).

mtrack user repos and ssh

I've just pushed a somewhat experimental change to the default branch of mtrack that enables per-user repositories, repository forking, SSH key management, and SSH repository serving integration.

It's important to stress that this is preliminary in as much as restrictive controls are missing. There are some ACLs and rights around repo creation that are not yet implemented. Additionally, if you are using OpenID, any authenticated user will be able to add an ssh key and access the mtrack created repos (but nothing outside of that).

What you get in the current tip:

  • Users can create Mercurial, Git or Subversion repositories
  • Delete your own repositories
  • Fork Mercurial or Git repositories
  • Associate your SSH keys with your mtrack login
  • Integration with SSH and Mercurial/Git/Subversion repo server

What you don't get (yet):

  • ACLs to control forking or access within repos
  • Pull requests, patch queue management
  • Graphs of forks and non-merged changes from forks

If you'd like to try these features, I'd love to hear your feedback. To update your instance:

$ hg pull
$ php bin/schema-tool.php

Then navigate to help.php/SSH (source text) to read about setting up SSH.


mtrack: burndown and postgres

It's that time of the month... mtrack update time. Not a huge number of items to report on this time around, but it's a decently significant stepping stone--the schema management code takes us one step closer to an upgrade/deployment process.

  • If you don't explicitly include the burndown macro text in a milestone, a default burndown graph will now be displayed when the milestone summary is rendered in the roadmap section.
  • Added schema management code to handle upgrades that change the schema
  • Added preliminary postgres DB support on top of the schema management code.
  • Revised attachment processing so that the database stores a canonical copy of each attachment. This step helps to enable multiple front-end web servers to be used with the same backend pgsql DB.
  • Created a stable branch that holds the changes up to just before the PostgreSQL DB changes

mtrack: custom fields, snippets

It's time for another mtrack update; here's what's new:

  • Add "Snippets" feature; works like pastebin, but allows for comments to be supplied in wiki syntax in addition to the code or text snippet that you're pasting
  • Add Custom Field support. This is implemented by modifying the schema (custom fields always have an "x_" prefix).
  • Improvements to the "custom ticket query" screens, including ability to select which columns (including custom fields) are included in the results
  • Fix an issue with sorting the "Remaining" time column
  • Fix some IE compatibility issues
  • Improve presentation of tickets in read-only mode
  • Refactor search engine code and allow the use of Apache Solr as an engine. Indexer logs are now viewable in the Admin section
  • Improve perceived search engine performance by forcing it to work in smaller batches
  • You may now delete attachments from both wiki pages and tickets
  • Add post commit hook for the wiki repo, so that changes made outside of the mtrack UI are noticed and indexed
  • Improve diff visualization
  • Add syntax highlighting facility
  • File view now allows blame and line numbers to be turned on or off, and renders with syntax highlighting
  • Allow optional "hour", "hours" and "hrs" unit after the spent time command in the commit hook (Thanks Andrei!)
  • Display remaining time as 0 if the ticket is closed

mtrack: facelift + other progress

I've been working on some changes to mtrack (a software development tracker implemented in PHP) this weekend, with a focus on improving the user experience for the mtrack administrator. To be brutally honest, it was at best a meagre experience for the administrator, but now things are better. They're still not perfect, but it should be a low enough bar to encourage more folks to play with mtrack. I've also spent a little bit of effort to add some caching to improve performance for certain pages.

For those that have tried it in the past, there's a brief summary of what's changed and a couple of screen shots below. This effort is in alignment with the roadmap that I published a little while ago.

mtrack: roadmap RFC

I wanted to share some of my thoughts on future development in mtrack, and solicit some feedback. Some of these are driven directly from user requests, and others are things that I've been thinking about on-and-off for a little while.

I really want to hear your thoughts, whether they relate to ideas and feature suggestions, or whether you have some experience or anecdotes on these topics.

Custom Fields

I was hoping to avoid having to enable this as a feature, as I find the implementation approach taken in the original Trac to be sub-optimal, both in terms of run time efficiency and in terms of user experience when it comes to reporting on the custom fields.

mtrack: now with OpenID and reCaptcha support

Some of the feedback and questions that I've gotten about mtrack were around making it easier to deploy and use in an open or public facing environment.

To that end, I've added support of OpenID authentication and bot detection via reCaptcha.

To enable these features is quite simple; for OpenID, add the following lines to your config.ini file:

MTrackAuth_OpenID =

You should also remove any other Auth plugins that you may have there, as how they interact with OpenID is not currently defined.

This will cause mtrack to keep users classes as anonymous until they either request to log-in via a link in the navigation bar, or attempt to access a page that requires privileges that the anonymous user lacks.

Users authenticating via OpenID can contribute to tickets and wiki (unless you change their permissions, either directly, or via their user class), and those changes will be attributed to them using their OpenID identity URL.

mtrack has a system for aliasing users from different repos and authentication schemes, so if you had a code contributor named "wez" in one of your repos, an administrator can add their OpenID URL as an alias via the user administration screens.  The admin user would edit the "wez" user and add "" to the list of aliases.  This will cause mtrack to see that OpenID as being equivalent to the "wez" user.

You can, if you wish, make an OpenID URL recognized as an admin user by adding the following lines to your config.ini:

[user_classes] = admin

This will have the effect of giving me admin rights to your mtrack install.

What about captchas?

Captcha's allow you to require that the person submitting a request be a human and not an automated submission agent.  In practical terms, this helps to avoid spam by limiting it to human spammers instead of spam bots.

To enable Captchas in mtrack using the reCaptcha service, go and register your domain and get yourself a private and public key pair.  Then add the following lines to your config.ini:

MTrackCaptcha_Recaptcha = pubkey, privkey

Where pubkey and privkey are your public and private keys respectively (you must not use double quotes).

This will cause a captcha to be displayed and checked in the wiki and ticket editing screens for anonymous and authenticated users; admin users will not see the captcha.


mtrack home page:

mtrack mailing list:

IRC: irc://

mtrack: a software development tracker + wiki

[Updated to add IRC and Google Groups links]

I don't know if it's just me, or whether everyone in software development finds issue tracking software frustrating and/or broken in some way.  They're all either way too complicated to set up, configure or use (the Bugzilla's or the Jira's), or have annoying "features" (such as Trac's you-lose-your-edits-if-someone-else-changed-something).

We've been using Trac at Message Systems for several years now and have been enjoying its pragmatic approach of keeping the interface simple but expressive; just enough structure to be helpful but not too much that it intrudes.  We've added/modified a couple of plug-ins to it to help track time and draw some graphs, but it has otherwise served us well.

However, we've got a couple of projects that have started to converge and overlap and it's frustrating to visit the two different portals to interact and stay on top of things.  As we scale up our development teams even further (we continue to have bigger and bigger plans!) this will prove to be more widely frustrating.

Enter mtrack; on one hand it's a clone of many of Trac's features (possible due to their pragmatic BSD license), but on the other it has some refinements in terms of its workflow.  What's important to me is that it is built to work with multiple code repositories and allows breaking out information on a per project basis.  It also tries hard to avoid losing your wiki or ticket edits if someone else updates things while you're working.

I chose to implement mtrack in PHP rather than continuing to extend Trac in python.  My primary reason for this is that I've seen web apps written with Perl and Python, and while there are certainly guru developers out there that can build some awesome apps, those languages don't really lend themselves to web development and that limits the scope of potential contributors.  While I can probably persuade some of my colleagues to code python web bits, I'll find it much easier to persuade more of them to code PHP web bits.  I'm sure this property extends outside of our organization.

We've been running our engineering department on mtrack for a couple of weeks now (after a period of running it in parallel to Trac) with just under 20 or so people using it actively as part of their day-to-day activities, so I feel comfortable in making this blog post to solicit input from the broader community, both in terms of suggestions and bug reports as well as potential contributions.

While I am soliciting feedback, I'd like to emphasize that this is still relatively young and that there is no support and no warranty; if you are the cautious type, this is not the time to try mtrack.

And now for some Anticipated Questions to pre-empt FAQ:

Where can I get mtrack?

How is mtrack licensed?

What are some of the key features in mtrack?

  • Trac style wiki syntax (all of its core syntax is supported)
  • Subversion and Mercurial repository integration (API extensible to other VCS)
  • Email notifications batch related information together to reduce the amount of mail you need to read; if you make 5 changes relating to a ticket in a 5 minute period you get one email with all 5 changes in it, instead of 1 per change.  Code changes that reference a ticket generate a single email with the ticket changes and the diff, not a separate email for each.
  • Issue tracking with configurable components, priorities, severities, milestones.
  • Define "projects" and associate components and paths within repositories with them to control who gets notified of changes.
  • Flot based graphing of Scrum burn-down based on time estimates and recorded effort
  • Wiki edits have in-built conflict resolution and the Issue tracker tries hard to behave reasonably in the case where multiple people are working on the same item.
  • Uses the Gravatar service to add some personality throughout the application.
  • Includes an importer to migrate your Trac project(s) into mtrack.
  • Has a plugin/hook API to support both core and external enhancements.
  • Uses the Zend Framework Lucene implementation for full-text search capabilities. 

Why didn't you use <Name of Framework>?

  • Frameworks can increase development overhead and I wanted to get this done.  Also, if I had used a framework, I would have to defend my choice against the others ;-). I am not morally opposed to contributions that adopt a framework, but would want to carefully assess the impact on longer term maintenance before doing so.

How do I install mtrack?

How can I contribute to mtrack?

  • By trying it out; I'm looking forward to hearing suggestions, comments and bug reports.  Please file them in the issue tracker: and keep in mind that you may not get a response until the following weekend (or even longer!) due to my busy schedule
  • By fixing bugs; if you've found and resolved an issue and want to pass a patch back to me you can do so either by attaching the patch or details on how to get at the patch to the issue tracker.  I recommend doing this by keeping your own fork on bitbucket as it makes it much more convenient for both of us.
  • By building out and sharing new features; I'm very open to adding new features.  My preference is to enable those by making the core modular enough that new features don't have to be part of the main mtrack code to be used by it.  This will keep the the core light and make it easier to share modules.
  • By fleshing out docs.  I'm the first to admit that mtrack could do with more documentation.
  • Join in the discussion in the mtrack mailing list or in the #mtrack IRC channel on freenode.

You started this article claiming that all other issue trackers suck, but I think mtrack needs improvement

  • I'm sure it does; it is still early days and I welcome your feedback (see above!)