Changes between Version 22 and Version 23 of TracMultipleProjects/ComprehensiveSolution

Timestamp:

Jun 29, 2007, 4:57:09 PM (17 years ago)

Author:

Dave Abrahams <dave@…>

Comment:

—

TracMultipleProjects/ComprehensiveSolution

@@ -8 +8 @@
  * '''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
+ * '''Single sign-on.''' Login once and skip around between Trac instances at will
    (subject to per-instance permissions, of course).
 
@@ -33 +33 @@
 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 [TracMultipleProjects 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.
 
+== Basic Strategy ==
+
+ * Use [http://www.postgresql.org/ PostGreSQL] to collect all projects into a single database using separate PostGreSQL "schemas."
+ * Use trachacks:MultipleProjectQueryFilterPlugin to fix up urls in those query results to point to the right tickets.
+ * Use [trachacks:TracForgePlugin TracForge] to get:
+  * Single Sign-On
+  * An improved project list
+ * ...
+
 == Requirements ==
 
+ * My port of the trachacks:TracForgePlugin to Trac 0.11dev ([http://trac-hacks.org/svn/tracforgeplugin/branches/bewst/0.11-clearsilver/ svn], [trachacks:browser:tracforgeplugin/branches/bewst/0.11-clearsilver browse]).
  * [http://genshi.edgewall.org/ Genshi] is required for Trac-0.11
- * My port of the trachacks:TracForgePlugin plugin to Trac 0.11dev ([http://trac-hacks.org/svn/tracforgeplugin/branches/bewst/0.11-clearsilver/ svn], [trachacks:browser:tracforgeplugin/branches/bewst/0.11-clearsilver browse]).
  * [http://www.clearsilver.net/ ClearSilver] is no longer used by Trac-0.11 since the switch to Genshi.  However, it contains a ClearSilver compatibility layer and the !TracForge plugin hasn't been ported to Genshi yet.
  * [http://www.postgresql.org/ PostGreSQL]
@@ -65 +74 @@
 
  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.
+
+== What's Wrong With [TracMultipleProjects/MultipleEnvironmentsSingleDatabase Previous Attempts] to Leverage !PostGreSQL Schemas? ==
+
+TracMultipleProjects/MultipleEnvironmentsSingleDatabase describes two approaches to using PostGreSQL schemas for doing multi-project reports:
+
+ * The first (main) approach probably works, but it fundamentally changes the layout of the database, so {{{trac-admin upgrade}}} [TracMultipleProjects/MultipleEnvironmentsSingleDatabase#Caveats will fail], maybe even spectacularly.  That wasn't acceptable to me.  
+
+ * The [TracMultipleProjects/MultipleEnvironmentsSingleDatabase#PossibleAlternative second (alternative) approach] is much simpler, but it also has a fatal flaw: although you can get a report, clicking any of the tickets still takes you to the ticket with the same ID as the ticket you clicked, but in the current project.
+
+== What's Wrong With [trachacks:TracForgePlugin TracForge] Ticket Subscriptions? ==
+
+[trachacks:TracForgePlugin TracForge] contains a featuere called "subscriptions" that replicates data from one trac instance to another.  One could try to use that to make all those tickets available in a master project where they can be queried.  However,
+
+ 1. Once the subscription is established, tickets are only replicated across Trac instances when new tickets are created.  That means I'm out-of-luck when it comes to querying across my pre-existing Trac instances.
+ 2. All that data replication is wasteful (this is minor) and probably slow (could be significant).
+ 3. This approach has basically the same flaw as the alternative approach above using PostGreSQL, just one level removed: yes, if you click on a ticket in the report, it takes you to a ticket with the '''right content...''' but that ticket is still in the '''wrong context'''...  so any project-local links to wiki pages changesets, etc. that are embedded in the ticket will take you to the wrong place.  One could try to patch the subscription code to fix them up, but in my opinion that is a hopeless fight.  To handle all the possible wiki syntax, you'd have to do a reverse translation for all the macros, plugins, etc. that introduce new wiki syntax.  There are just too many to possibly account for all of them, and trying to keep up with new ones would be a maintenance nightmare.
+