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).
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:
What you don't get (yet):
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.
Enjoy!
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.
It's time for another mtrack update; here's what's new:
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.
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.
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.
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:
[plugins]
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 "http://netevil.org/" 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]
http://netevil.org/ = 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:
[plugins]
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.
Enjoy!
mtrack home page: http://bitbucket.org/wez/mtrack/wiki/Home
mtrack mailing list: http://groups.google.com/group/mtrack
[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?
Why didn't you use <Name of Framework>?
How do I install mtrack?
How can I contribute to mtrack?
You started this article claiming that all other issue trackers suck, but I think mtrack needs improvement