We use RT here for our trouble ticket system and the dashboard
can easily be configured to display tickets based on any search
criteria and you can have multiple views on the same screen.
The search functionality can be viewed as the tool for configuring
your views into the system, for whatever its purpose may be. It
is easy to organize the views based on keywords, milestones, or
anything else. It really is very flexible and its E-mail interface
is very nice as well.
Regards,
Ken Marshall
On Fri, Apr 11, 2008 at 06:46:18PM +0100, Gregory Stark wrote:
> "Brendan Jurd" <direvus@gmail.com> writes:
>
> > In Trac, if I just want to loosely associate several tickets together
> > I'd use *keywords*, e.g., put "index am" in the keywords list for
> > several tickets, and then they'll show up prominently when I search
> > for those terms.
>
> As an aside, you've reminded me about another thing that bothers me about
> Bugzilla and RT. In both cases they seem to put a lot of focus around the idea
> of "searching" bugs. I don't really get why.
>
> Maybe it makes sense if you plan to be like Mozilla and have 8-year-old bugs
> that nobody ever sees let alone updates, but surely that isn't the goal.
>
> In fact it seems like having the UI centred around "searching" pretty much
> dooms you to that fate. Of course things will fall through the cracks if your
> main UI only presents the things you decide to go look for.
>
> I would think an interface which presents you with *all* unclosed bugs by
> default, perhaps organized in some way (keywords, milestones, etc) would be
> more conducive to getting attention to everything.
>
> I'm sure you can do something like that in Bugzilla and RT but it sure doesn't
> seem to be the way it's used in practice.
>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
> Ask me about EnterpriseDB's RemoteDBA services!
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
