Re: [Trac] Multiple product in one Trac application
53 views
Skip to first unread message
Benjamin Lau
Nov 22, 2012, 3:15:18 PM11/22/12
to trac-...@googlegroups.com
I've dealt with this both ways actually. So here are my experiences.
1. Separate Trac Instances per Product
This will work. You put all your tickets into separate Trac instances
for each of your products. The problem here is that you now have 2 (or
more) Trac instances with their own wiki as well. As long as you are
careful about where you put any documentation (or disable the wiki
entirely) this will work pretty well... with one caveat. For whatever
reason people tend to refer to tickets by their number as a quick
shorthand. For example: "That bug is written up in 2531." If you've
got two instances of Trac each with their own ticket numbers you can
get collisions and it makes it hard to know which project a particular
ticket goes with.
If you need to provide customers or other contractors access to only
parts of your wiki or for a project you work on only with them this
might also be a good option since you can make sure that the content
in the Trac instance is only for them. I use this approach for some
projects so I can share documentation and such. (Though you can
accomplish something similar using the
http://trac.edgewall.org/wiki/AuthzPolicy for the wiki only.)
2. Custom Fields or Keyword
This is my preferred method. As you already noted this seems like the
logical way to manage this. I tend to use keywords (since I can then
use the same tag on wiki pages and generate lists of all the related
items in the wiki, tickets, and the blog (FullBlogPlugin) with some
simple stuff in a wiki page.
To help with managing this I like to create a page in the wiki for
each of the products which provide some quick links for creating
tickets with the correct defaults. Here's a sample for one which
creates tickets for myself in one of my Trac instances. I don't have
access to my product examples since those live in a previous
employer's wiki. But these show the general idea and should be pretty
easy to adapt (I added keywords usage since that's the easiest way to
do this... use a custom field if you want to make sure nobody ever
messes it up. :-).
Create new '''[/newticket?type=task&owner=ben&keywords=project
task]|[/newticket?type=defect&owner=ben&keywords=project
defect]|[/newticket?type=enhancement&owner=ben&keywords=project
enhancement]''' for ben
I also like to create a chunk of the page to show all the tickets that
match a particular state. This makes use of the TicketQuery macro:
||'''Backlog'''
([[TicketQuery(keywords=project,owner=ben,status!=closed&status!=accepted,format=count)]])||
\
||'''Active Tasks'''
([[TicketQuery(keywords=project,owner=ben,status=accepted,format=count)]])||
\
||'''Completed in the past 30 days:'''
[[TicketQuery(keywords=project,owner=ben,status=closed,format=count,modified=30daysago..)]]
'''All time:'''
[[TicketQuery(keywords=project,owner=ben,status=closed,format=count)]]||
||[[TicketQuery(keywords=project,owner=ben,status!=closed&status!=accepted,format=table,col=summary,order=changetime,desc=true)]]||
\
||[[TicketQuery(keywords=project,owner=ben,status=accepted,format=table,col=summary,order=changetime,desc=true)]]||
\
||[[TicketQuery(keywords=project,owner=ben,status=closed,format=table,col=summary,modified=30daysago..,order=modified,desc=1)]]||
Hope that's useful.
Ben
On Wed, Nov 21, 2012 at 8:39 AM, Dale Ellis <daleel...@gmail.com> wrote:
> Hi all,
>
> I have been using Trac for well over a year now and have just noticed that
> has been a new release and have been reading the release notes to get an
> idea of what's in it.
>
> The big thing for me is that we have multiple products but there is no clear
> separation of what tickets apply to which application so am hoping that is
> something in the latest release that caters for that.
>
> For example I have a CRM product and a BPM product. I have created different
> milestones for the various impending releases of the 2 products, there are
> various components I have created in trac which apply to a specific product,
> but other than that there is no way to tell what ticket belongs to that
> product. I guess I could create custom queries and wiki pages to show the
> product specific tickets but that requires maintenance and ideally I could
> view the roadmap for CRM product or BPM product.
>
> So my question is, how do people do about separating tickets at a product
> level? Is there anything in version 1.0 that assists with this? I think I
> read in the release notes that I can config Trac to have custom fields, is
> this how people do it? Or do people just run multiple instances of Trac?
>
> Looking forward to hearing how people use Trac,
> TIA, Dale
>
> --
> You received this message because you are subscribed to the Google Groups
> "Trac Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/trac-users/-/85COmxp0_bYJ.
> To post to this group, send email to trac-...@googlegroups.com.
> To unsubscribe from this group, send email to
> trac-users+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/trac-users?hl=en.
1. Separate Trac Instances per Product
This will work. You put all your tickets into separate Trac instances
for each of your products. The problem here is that you now have 2 (or
more) Trac instances with their own wiki as well. As long as you are
careful about where you put any documentation (or disable the wiki
entirely) this will work pretty well... with one caveat. For whatever
reason people tend to refer to tickets by their number as a quick
shorthand. For example: "That bug is written up in 2531." If you've
got two instances of Trac each with their own ticket numbers you can
get collisions and it makes it hard to know which project a particular
ticket goes with.
If you need to provide customers or other contractors access to only
parts of your wiki or for a project you work on only with them this
might also be a good option since you can make sure that the content
in the Trac instance is only for them. I use this approach for some
projects so I can share documentation and such. (Though you can
accomplish something similar using the
http://trac.edgewall.org/wiki/AuthzPolicy for the wiki only.)
2. Custom Fields or Keyword
This is my preferred method. As you already noted this seems like the
logical way to manage this. I tend to use keywords (since I can then
use the same tag on wiki pages and generate lists of all the related
items in the wiki, tickets, and the blog (FullBlogPlugin) with some
simple stuff in a wiki page.
To help with managing this I like to create a page in the wiki for
each of the products which provide some quick links for creating
tickets with the correct defaults. Here's a sample for one which
creates tickets for myself in one of my Trac instances. I don't have
access to my product examples since those live in a previous
employer's wiki. But these show the general idea and should be pretty
easy to adapt (I added keywords usage since that's the easiest way to
do this... use a custom field if you want to make sure nobody ever
messes it up. :-).
Create new '''[/newticket?type=task&owner=ben&keywords=project
task]|[/newticket?type=defect&owner=ben&keywords=project
defect]|[/newticket?type=enhancement&owner=ben&keywords=project
enhancement]''' for ben
I also like to create a chunk of the page to show all the tickets that
match a particular state. This makes use of the TicketQuery macro:
||'''Backlog'''
([[TicketQuery(keywords=project,owner=ben,status!=closed&status!=accepted,format=count)]])||
\
||'''Active Tasks'''
([[TicketQuery(keywords=project,owner=ben,status=accepted,format=count)]])||
\
||'''Completed in the past 30 days:'''
[[TicketQuery(keywords=project,owner=ben,status=closed,format=count,modified=30daysago..)]]
'''All time:'''
[[TicketQuery(keywords=project,owner=ben,status=closed,format=count)]]||
||[[TicketQuery(keywords=project,owner=ben,status!=closed&status!=accepted,format=table,col=summary,order=changetime,desc=true)]]||
\
||[[TicketQuery(keywords=project,owner=ben,status=accepted,format=table,col=summary,order=changetime,desc=true)]]||
\
||[[TicketQuery(keywords=project,owner=ben,status=closed,format=table,col=summary,modified=30daysago..,order=modified,desc=1)]]||
Hope that's useful.
Ben
On Wed, Nov 21, 2012 at 8:39 AM, Dale Ellis <daleel...@gmail.com> wrote:
> Hi all,
>
> I have been using Trac for well over a year now and have just noticed that
> has been a new release and have been reading the release notes to get an
> idea of what's in it.
>
> The big thing for me is that we have multiple products but there is no clear
> separation of what tickets apply to which application so am hoping that is
> something in the latest release that caters for that.
>
> For example I have a CRM product and a BPM product. I have created different
> milestones for the various impending releases of the 2 products, there are
> various components I have created in trac which apply to a specific product,
> but other than that there is no way to tell what ticket belongs to that
> product. I guess I could create custom queries and wiki pages to show the
> product specific tickets but that requires maintenance and ideally I could
> view the roadmap for CRM product or BPM product.
>
> So my question is, how do people do about separating tickets at a product
> level? Is there anything in version 1.0 that assists with this? I think I
> read in the release notes that I can config Trac to have custom fields, is
> this how people do it? Or do people just run multiple instances of Trac?
>
> Looking forward to hearing how people use Trac,
> TIA, Dale
>
> --
> You received this message because you are subscribed to the Google Groups
> "Trac Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/trac-users/-/85COmxp0_bYJ.
> To post to this group, send email to trac-...@googlegroups.com.
> To unsubscribe from this group, send email to
> trac-users+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/trac-users?hl=en.
Brettschneider Falk
Nov 23, 2012, 2:18:45 AM11/23/12
to trac-...@googlegroups.com
Dale Ellis wrote:
> The big thing for me is that we have multiple products but there is no clear separation of what tickets apply to which application so am hoping that is something in the latest release that caters for that.
Look at SimpleMultiProjectPlugin which does supports what you need. The additional custom ticket field 'project' is what you would call 'product'. It's all living in one Trac instance. That project requires at least 0.12.
> The big thing for me is that we have multiple products but there is no clear separation of what tickets apply to which application so am hoping that is something in the latest release that caters for that.
CU, F@lk
----
Falk Brettschneider
R&D Software
Baumer Optronic GmbH
www.baumer.com
Geschäftsführer: Dr. Albert Schmidt· Dr. Oliver Vietze
Sitz der Gesellschaft: Radeberg
Amtsgericht Dresden: HRB 15379
Ust. ID: DE 189714583
RjOllos
Nov 26, 2012, 3:02:08 AM11/26/12
to trac-...@googlegroups.com
On Thursday, November 22, 2012 12:15:45 PM UTC-8, netjunki wrote:
[...]
2. Custom Fields or Keyword
This is my preferred method. As you already noted this seems like the
logical way to manage this. I tend to use keywords (since I can then
use the same tag on wiki pages and generate lists of all the related
items in the wiki, tickets, and the blog (FullBlogPlugin) with some
simple stuff in a wiki page.
Cool idea. You could even make menu entries for those links, using MenusPlugin and NavAddPlugin. I've had them both working together, but it takes a bit of care for some subtle issues. MenusPlugin could use some updating, but still functions with Trac 1.0 last time I checked.
Olemis Lang
Nov 23, 2012, 11:36:50 AM11/23/12
to trac-...@googlegroups.com
:)
> I have been using Trac for well over a year now and have just noticed that
> has been a new release and have been reading the release notes to get an
> idea of what's in it.
>
environment , by using custom ticket fields , and also provides
product dashboard .
You can see it in action (multiproduct disabled at the moment ... though ) here
http://issues.apache.org/bloodhound/
Installation instructions
https://issues.apache.org/bloodhound/wiki/BloodhoundInstall
> Looking forward to hearing how people use Trac,
... beyond that , some important enhancements are being developed at
the moment .
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
> I have been using Trac for well over a year now and have just noticed that
> has been a new release and have been reading the release notes to get an
> idea of what's in it.
>
> The big thing for me is that we have multiple products but there is no
> clear separation of what tickets apply to which application so am hoping
> that is something in the latest release that caters for that.
>
Apache™ Bloodhound provides a solution for that within a single
> clear separation of what tickets apply to which application so am hoping
> that is something in the latest release that caters for that.
>
environment , by using custom ticket fields , and also provides
product dashboard .
You can see it in action (multiproduct disabled at the moment ... though ) here
http://issues.apache.org/bloodhound/
Installation instructions
https://issues.apache.org/bloodhound/wiki/BloodhoundInstall
> Looking forward to hearing how people use Trac,
the moment .
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Reply all
Reply to author
Forward
0 new messages