| 31 | | 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 multiple Trac instances per day as you review your most active projects. Additionally, 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 important. |
| | 31 | When you host multiple Trac projects, it is 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 multiple Trac instances per day as you review your most active projects. Additionally, 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 important. |
| 117 | | * 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. See also #1316. |
| | 117 | * 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 [th:PrivateTicketsPlugin Private Tickets Plugin] can do the first part of the job for me (using the old permissions system), but not the second. See also #1316. |
| 137 | | 1. 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 account for all of them, and trying to keep up with new ones would be a maintenance nightmare. |
| | 137 | 1. 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 account for all of them, and trying to keep up with new ones would be a maintenance nightmare. |
| 142 | 142 | |
| 143 | 143 | - ''Just a quick feedback to mention that at this point, '''what''' your solution is isn't immediately clear ;-). From the ''requirements'' section below it appears that it is based on !TracForge, so maybe this should be made more clear from the start. Note that !TracForge itself is probably implementing something quite close to what is discussed in TracMultipleProjects/MultipleEnvironments.'' [[br]]-- cboos 06/25/2007 11:02:46 AM |
| 144 | 144 | - ''I think most of that should be clear now.'' My earlier response: ''Yes, I know. As I said, "work in progress," which I hope to have finished in the next few days. I'm actually combining stuff from !TracForge, various other plugins from TracHacks, stuff from TracMultipleProjects/MultipleEnvironmentsSingleDatabase, and some of my own code. The approach for supporting cross-project queries is entirely different from what !TracForge does, so characterizing it as "based on !TracForge" won't really tell people what it is.'' [[br]]-- dave 06/28/2007 04:45:59 PM |
| 145 | 145 | - Is there a possibility to reach the same thing with sqlight? |
| 146 | | - ''Not in this way; this particular scheme relies on the unique ability of PostGreSQL to use multiple schemas in the same database and do queries across those schemas. If you don't care about cross-project queries, then of course SQLite should work fine.'' [[br]] -- dave 01/28/2008 |
| 147 | | - The migration and multitrac query use schema but do not actually use the inheritance feature in postgresql, so its not clear to me how this is actually much more than a union query where the joined queries are set in a loop. If you use inheritance, you could simplify the multitrac_query to be a join like "select bar, relname from foo join pg_class on pg_class.oid=foo.tableoid;" This does not alter the trac schema at all, so I think trac DDL changes with version upgrades should work. I've modifiyed sqlite2pq and migrate.py to use inheritance. Any interest in persuing this variation on your approach? [[br]] -- karl 04/13/2008 |
| 148 | | - ''Karl, I didn't know anything about table inheritance in postgresql when I did this, but now that I look, it seems like that could be used to substantially improve on my scheme. I still don't have very strong DB-fu so I'd need some handholding, but I _would_ like to pursue your idea. Please be in touch with me at dave-AT-boostpro-dotcom. [[br]] --dave 05/29/2008 |
| | 146 | - ''Not in this way; this particular scheme relies on the unique ability of PostgreSQLto use multiple schemas in the same database and do queries across those schemas. If you don't care about cross-project queries, then of course SQLite should work fine.'' [[br]] -- dave 01/28/2008 |
| | 147 | - The migration and multitrac query use schema but do not actually use the inheritance feature in PostgreSQL, so its not clear to me how this is actually much more than a union query where the joined queries are set in a loop. If you use inheritance, you could simplify the multitrac_query to be a join like "select bar, relname from foo join pg_class on pg_class.oid=foo.tableoid;" This does not alter the trac schema at all, so I think trac DDL changes with version upgrades should work. I've modifiyed sqlite2pq and migrate.py to use inheritance. Any interest in persuing this variation on your approach? [[br]] -- karl 04/13/2008 |
| | 148 | - ''Karl, I didn't know anything about table inheritance in PostgreSQL when I did this, but now that I look, it seems like that could be used to substantially improve on my scheme. I still don't have very strong DB-fu so I'd need some handholding, but I _would_ like to pursue your idea. Please be in touch with me at dave-AT-boostpro-dotcom. [[br]] --dave 05/29/2008 |
