Changes between Version 9 and Version 10 of TracMultipleProjects/ComprehensiveSolution

Timestamp:

Jun 24, 2007, 8:26:06 PM (17 years ago)

Author:

Dave Abrahams <dave@…>

Comment:

—

TracMultipleProjects/ComprehensiveSolution

@@ -40 +40 @@
  * making trac.ini adjustments across all projects
 
-== What's Wrong With [TracMultipleProjects/SingleEnvironment Using a Single Trac]? ==
+== What's Wrong With Sharing a Single Trac? ==
 
-It doesn't work to ask our customers to [TracMultipleProjects/SingleEnvironment 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 automatically exposed to the world. 
+There's been some work on [TracMultipleProjects/SingleEnvironment 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. 
 
-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:
+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 [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.    
+ * 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 [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 the system probably needs to be more flexible than what I've described.