A Comprehensive Multi-Project Solution

Abstract: we present a comprehensive solution for many of the problems of maintaining or participating in multiple projects under Trac. We briefly analyze some of the other approaches and explain why we're not using them.

This method supports:

• Cross-project ticket queries. Find out what your most important issues are in one swell foop.

• Single login. Login once and skip around between Trac instances at will (subject to per-instance permissions, of course).

• Central configuration. You'll no longer have to edit multiple trac.ini files just to make a configuration change across many Trac instances.

Caveats

• This page is a work in progress. I've solved the technical issues on my local development server and am composing this page as I port my real Trac instances over to the new system.

• This method requires the use of not-yet-released versions of Trac, ​Genshi, and several plugins, available from those projects' Subversion repositories.

Note: this solution obviously owes much to the work of others; I'm not claiming to be an innovator here, just an integrator.

Just How Comprehensive Is This Solution, Really?

Ticket #130 contains a long, rambling, and extremely enlightening discussion of what people need from multi-project support. Anyone who has read that thread, and the other pages proposing different ways to support multiple projects, knows that my solution isn't going to work for everyone. Nonetheless, I think I've hit a "sweet spot" that gives most people most of what they're looking for, and more importantly, can be (relatively) easily set up today by anyone. So while my claim of having a "comprehensive" solution might be seen as grandiose, I think it's supportable.

Requirements

• ​Genshi is required for Trac-0.11

Niceties

• ​Pygments is the new default syntax highlighter for Trac, but you may need to install it separately.

Motivation

When you host multiple trac projects, its very common to have users that are members of more than one of these projects. If, like ​me, you're using your Tracs to support multiple customers, you probably need to be a member of each trac instance. Even when using a TRAC_ENV_PARENT_DIR setup, one typically ends up having to log in to three or four Trac instances a day as you review your most active projects. Just having to log in over and over is problematic in itself. Worse, if you're tracking tickets in several projects, there's no way to see them all together in stock Trac. You actually need to log into each project and check your tickets there, and it becomes very likely that you'll miss something really important.

The other problem is that, when administering multiple similar tracs, you end up repeating the same configuration steps over and over. The tedious jobs include:

• creation and initialization of new trac instances
• setting up common user permissions
• making trac.ini adjustments across all projects

What's Wrong With Sharing a Single Trac?

There's been some work on managing multiple projects within a single Trac instance, but Trac can't yet give my customers the privacy they need in a shared environment. Sometimes we're working on proprietary software that must be kept private, but even when we're working on open source, customers generally feel uncomfortable when all their issues are automatically exposed to the world.

There are at least two areas that need to be improved in Trac to make a shared Trac workable:

• TracDev/SecurityBranch (which, despite its name, is on Trac's trunk now) needs to be extended to cover Trac resources other than Wiki pages.
• We need a flexible and automatic way to attach these permissions to resources upon creation. In my usage model, when a customer enters a ticket, it should be visible to and writable by everyone in his company and everyone in my company, but nobody else. Also, I occasionally need to create a ticket myself, with those same properties, and assign it to the customer. These capabilities are outside the scope of TracDev/SecurityBranch, so they need to be addressed separately. The ​Private Tickets Plugin can do the first part of the job for me (using the old permissions system), but not the second.

Naturally, the same kinds of issues apply to other resources such as Milestones. Upon creation by a customer, they need to be private to that customer and (some subset of) my people. When I create these resources there needs to be an easy way to make them private to a particular customer's company. And I'm sure that other people will have vastly different "permission workflow" requirements than I do, so the system probably needs to be more flexible than what I've described.

Troubleshooting

I have applied a few small patches to my local trac installation to work around various bugs in Trac or in plugins. I'm not sure that these bugs will show up for you when implementing this solution (and it's very likely they've already been fixed by the trac team), but in the interest of full disclosure, here they are:

• ticket:4547 describes a problem where python generates errors because datetime objects and numeric types such as float don't interoperate. The latest patch at the time of this writing is attached to the ticket: #4547/datefmt-r5696.diff.
• If Trac tells you to run "trac-admin /path/to/your/environment upgrade, and it fails with "iteration over a non-sequence", apply the tiny patch shown in #5593.