Integrate bug tracker configuration with the hosting service support.
Review Request #3131 — Created May 31, 2012 and submitted
Integrate bug tracker configuration with the hosting service support. The repository form now allows for configuration of bug trackers again. The possible trackers are pulled from the list of hosting services. A hosting service can now specify whether it supports repositories, bug trackers, or both. There's a mixture now of each type. Bugzilla, Trac, and Redmine services have been added, and are all currently for bug trackers only. Some of the fields in HostingService (repository_form, repository_plans) have been changed to be more generic. Some new functionality has also been added to make it easier to query for the information we need. The repository form, of course, is the bulk of this work. Like a repository's hosting service, all the field data is stored in Repository.extra_data. This reuses the same forms that repository configuration use, but adds a "bug_tracker-" prefix to the keys. Unlike with repositories, though, there's no concept of linking an account. Instead, there's just a username field, when the bug tracker needs it. In the future, when we need deeper integration into bug trackers, that may change, though we'll need to promote bug trackers to being more like repositories, and change the configuration workflow a bit. Existing bug trackers will not be categorized under the service type. They will all appear as Custom. It would be possible to reverse-map it, like we used to, but it will get it wrong in many cases (such as with GitHub, as each plan's bug tracker's pattern is interchangeable). Right now, all the configuration continues to update the Repository.bug_tracker field, which is still used for all display. We will probably want to change that down the road to dynamically compute the bug tracker URL on demand, since it's possible for those URLs to change in a HostingService in new releases. That needs some thought, though. This does not yet provide new unit tests. Those are coming next.
Hand-tested with various configurations, and verified that the data was stored properly in the database. Existing unit tests run.
Added unit tests, and fixed a few code paths that were hit as a result. View the interdiff for the latest.
Revision 2 (+908 -343)