Changes between Version 11 and Version 12 of TracDev/Proposals/MultipleProject

Timestamp:

Nov 23, 2014, 11:42:25 PM (9 years ago)

Author:

Christian Boos

Comment:

start to modify #DataModel

TracDev/Proposals/MultipleProject

@@ -126 +126 @@
 == The Data Model == #DataModel
 
-The main idea is to attach a project identifier to each resource.
+The main idea is to associate a resource to one or several projects.
 
-This can be achieved either by using an extra `.project` field for each resource or by parenting the resources in a project resource.
-The second way is probably better, as some resources might be project independent (like the Changeset and Source which belong to a given repository - see MultiRepos).
+This can be achieved by using an extra project association table for each resource.
 
-The empty string `''` could be used to qualify the toplevel project, which is always there. If no other project has been defined, then Trac behaves as usual, one environment is one project. As soon as other projects are defined, the environment becomes a multi-project one.
+Some resources might be only indirectly related to a project, like the Changeset and Source which belong to a given repository (see MultiRepos). The repository object itself might be related to some projects.
 
-Independently from the GenericTrac specification, the MultiProject changes to the data model are quite simple.
-The only backward incompatible addition needed is a `project` field to most of the resource related tables.
+Likewise, some resources might stay "global" for a while, like the Wiki pages, or even the Milestone and Version in the first steps. We'll first focus on the Ticket.
 
-An additional `project` table is also needed, and it can take the form of a ''resource table specialization'' from the GenericTrac. Projects should have at least a ''description'' field, an ''owner'' and a ''status'' field. Projects can be linked explicitly to shared data. For example, each projects can be linked to its own set of repositories.
+The empty string `''` could be used to qualify the top-level project, which is always there. If no other project has been defined, then Trac behaves as usual, one environment is one project. As soon as other projects are defined, the environment becomes a multi-project one.
 
-For resource specific SQL queries, the appropriate `project` identifier will have to be specified in addition to the `realm` (if needed) and `id` information.
+An additional `project` table is also needed, and it can take the form of a ''resource table specialization'' described in GenericTrac. Projects should have at least a ''description'' field, a ''creator'' and a ''status'' field. Projects can be linked explicitly to shared data. For example, each projects can be linked to its own set of repositories.
 
 For SQL queries that may cover more than one project, a helper method can be used to form the include/exclude constraints, given the project pattern list that has to be used.
 
-On the API side, the multiproject nature will be mostly transparent except when instantiating and manipulating resources, which will have an additional `project` field. Legacy resources and legacy code not taking the project into account will simply fallback to accessing resources at the global level, which will work just fine in single project environments.
+On the API side, the multi-project nature will be mostly transparent except when instantiating and manipulating resources, which will have an additional `project` field. Legacy resources and legacy code not taking the project into account will simply fallback to accessing resources at the global level.
 
 
 == Web User Interface Changes ==
  ''needs to be amended to take [#ProjectTree] into account''
-There should be a few standard ways to switch the project, either a pull-down menu or a tab-bar (in the style of edgewall.org).
+There should be a few standard ways to switch the project, e.g. a pull-down menu as described in [#Focalproject] above.
 
-The toplevel project should also be able to present a ''Projects'' main navigation entries, showing a list of the available projects, much similar to the list of Milestones.
+The top-level project should also be able to present a ''Projects'' main navigation entries, showing a list of the available projects, much similar to the list of Milestones.
 
 An admin module can be used to create new projects (eventually copying settings from another one), renaming projects and deleting them.
 
 Existing modules that lend themselves to cover multiple projects should be adapted and provide a standard way to specify multiple projects when accessed from the toplevel project. This can take the form of a list of checkboxes, a multiple selection field, or a text field for entering a pattern.
-When those modules are accessed within a dedicated project (parameter 'project'), they should behave similarly to the single project Trac, i.e. not offer the possibility to cover different projects. But when the project is the toplevel one (`project == ''`) or there are already multiple projects specified, then the possibility to select different projects should be offered.
+When those modules are accessed within a dedicated project (parameter 'project'), they should behave similarly to the single project Trac, i.e. not offer the possibility to cover different projects. But when the project is the top-level one (`project == ''`) or there are already multiple projects specified, then the possibility to select different projects should be offered.
 
 == Utilities ==