Edgewall Software
Modify

Opened 6 years ago

Last modified 6 months ago

#11086 new enhancement

Filter options for roadmap

Reported by: anonymous Owned by:
Priority: normal Milestone: unscheduled
Component: roadmap Version: 1.0
Severity: normal Keywords: javascript plugin
Cc: warwing@… Branch:
Release Notes:
API Changes:

Description

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?

Attachments (0)

Change History (5)

comment:1 by Christian Boos, 6 years ago

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.

comment:2 by anonymous, 6 years ago

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 ?

in reply to:  2 comment:3 by Christian Boos, 6 years ago

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…

comment:4 by Christian Boos, 6 years ago

Keywords: javascript plugin added
Milestone: unscheduled

comment:5 by anonymous, 6 months ago

Related: #2588, #7342

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set.
The owner will be changed from (none) to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.