Changes between Version 6 and Version 7 of TracMultipleProjects/ComprehensiveSolution

Timestamp:

Jun 24, 2007, 7:46:54 PM (17 years ago)

Author:

Dave Abrahams <dave@…>

Comment:

—

TracMultipleProjects/ComprehensiveSolution

@@ -34 +34 @@
 When you host multiple trac projects, its very common to have users that are members of more than one of these projects.  If, like [http://boost-consulting.com/about/people 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 [TracFastCgi#SimpleApacheConfiguration 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. 
 
-repeating the same configuration steps over and over 
+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:
 
-It doesn't work to ask our customers to [TracMultipleProjects/SingleEnvironment share the same Trac instance]. Customers need privacy, and Trac isn't yet up to the task of [TracDev/SecurityBranch managing fine-grained permissions] on individual [WikiContext resources].  Sometimes we're working on proprietary software that ''must'' be kept private, but even when we're working on open source, customers generally feel more comfortable when their issues are not exposed to the world. 
+ * creation and initialization of new trac instances
+ * setting up common user permissions
+ * making trac.ini adjustments across all projects
+
+== What's Wrong with TracMultipleProjects/SingleEnvironment? ==
+
+It doesn't work to ask our customers to share the same Trac instance. Customers need a sense privacy.  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 not automatically exposed to the world. 
+
+Although there's been some work in this area, Trac can't yet give my customers the privacy they need.  There are at least two areas that need work in Trac to change that:
+
+ * TracDev/SecurityBranch (which, despite its name, is on Trac's trunk now) needs to be extended to cover [WikiContext Trac resources] other than Wiki pages. 
+ * 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 [http://trac-hacks.org/wiki/PrivateTicketsPlugin 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 it needs to be flexible.
 
 == Troubleshooting ==