Filter options for roadmap

[anonymous]

Hello together,

I plan to use trac as primary change management tool for our application suite at work. Even in our test environment we currently have about 40 milestones. For our business people, which are not so familiar with trac, it is hard to work with the roadmap view.

When a milestone is closed, they have to select "show completed milestones", which results in a very long list of milestones.

It whould be great if there was a filter mechanism like in the timeline.

"Show me all completed milestones starting from <date> and the last <n> days before"

Another cool filter would be: "Show me all (completed) milestones containing tickets for component <c>"

Do you agree with this feature request or would say it's not necessary and I should try another way?

[Christian Boos]

Well, the feature certainly sounds useful for your use case. But it's likely not pertinent for the default configuration of Trac.

So all the question is how could this could be achieved via a plugin. There's no "IRoadmapFilterProvider" extension point, nor should there be one I think.

We need to find a way to gradually evolve towards a more dynamic architecture where such extensions could be done via a JavaScript. This could be a typical use case.

[anonymous]

When I understand you correctly you wouldn't accept a patch for the roadmap that implements the functionality directly because your default setup has different requirements.

Well, let me ask a question about the intended use of trac: We have an application suite (numerous business modules in an application framework which will be deployed on the same application server - and currently packaged in an ear equivalent).

From my point of view there are two possible environment setups:

• Everything in one trac environment
• One master environment for framework and wiki and one environment per business module

Are there any restrictions from a performance perspective with a singe environment (I assume we will have about 5.000 tickets per year…).

The test environment uses sqlite as database and is currently not as fast as it could be (with currently 300 tickets). Will the performance scale that much better with a database like mysql or postgres?

Should I start with one enviroment and wait for ​http://trac-hacks.org/wiki/SimpleMultiProjectPlugin ?

[Christian Boos]

Replying to anonymous:

When I understand you correctly you wouldn't accept a patch for the roadmap that implements the functionality directly because your default setup has different requirements.

Well, I'm afraid the balance complexity added to Trac / specialization of the need wouldn't be favorable. But I may be proved wrong.

Well, let me ask a question about the intended use of trac:

Well, such discussion should better take place on the mailing list, you'll reach more people practiced with deploying Trac. I'll only answer briefly here.

We have an application suite (numerous business modules in an application framework which will be deployed on the same application server - and currently packaged in an ear equivalent).

From my point of view there are two possible environment setups:

• Everything in one trac environment
• One master environment for framework and wiki and one environment per business module

With the second options, you'll have trouble getting an overview and lots of repeated administrative tasks (setting the same milestones, versions etc. could be automated a bit with trac-admin, but still).

Are there any restrictions from a performance perspective with a singe environment (I assume we will have about 5.000 tickets per year…).

That should be fine with the appropriate DB, probably PostgreSQL.

Should I start with one enviroment and wait for ​http://trac-hacks.org/wiki/SimpleMultiProjectPlugin ?

Starting with one environment seems a good choice, given you probably have lots of inter-relations between modules. Like in most enterprise setups, I think you ideally need something like a hierarchy of projects, something like #11025. We'll get there…

[anonymous]

Related: #2588, #7342