Can Trac help me build my ideal issue tracking system?

[Devin Jacobs]

I've been thinking about writing a issue tracking system myself,
because I feel the existing options are all too complicated for my
needs. I'm a Python fan, so Trac was first on my list. I figure Trac
will either support the workflow I want in my issue tracking system or
I can find ways to contribute and customize Trac.

In a sentence: I'm looking for a system to help organize tasks among
several users and several projects, and the system should serve as an
archive for discussions and files related to these tasks.

More telling is that I don't need any features related to programming
and source code, timelines, roadmaps, a wiki, etc.

All the issue trackers I'm aware of just have too many features given
prominent display when they're not needed. Users complain that
there's 20 fields on the screen and they only ever use 2 or 3.

The system I've envisioned is build with 3 key concepts, which I'll
explain:

Users - A user account, email, password, etc. A user interacts with
the issues they have access (permission) to. A user may have access
to an issue either directly or through a group membership.

Groups - A group of users. A group can have many users, and a user
can belong to many groups. Permissions granted to the group are
granted to the groups members. A group can also contain other
groups. (I've seen "roles" distinguished from groups in some systems,
by allowing groups to contain other groups you can have complex
multilayer grouping. If an administrator insists on using "roles"
then they can create these roles as groups.)

Issue Types - A definition or template of a specific issue type.
Issues are all instances of an Issue Type. Each Issue Type can have
several attributes or fields. Each attribute has fine grained access
controls, so you might allow a user to only see a certain attribute,
and only have read access to that attribute. Attributes would be
things like "pick list", "user pick list", "text field", "discussion",
"file". Creating Issue Types would be the most complex task in the
application, but wouldn't need to be done often.

An example Issue Type might be a software bug. You define a software
bug to have a title (a free form text field), assigned to (user pick
list), and priority (pick list, with "high" and "low"), estimated work
required (a free for text field), discussion (a place for discussion,
similar to typical web forums). You make the estimated work required
field editable by developers only, since only a developer is qualified
to make that estimate; yet the manager could still view the estimate
once it was made.

The ultimate goal of this system would be to minimize the amount of
irrelevant information users have to see.

My system wouldn't directly support multiple projects, but through
managing permission and properly organizing users and group you could
achieve the same thing. Users of the Project_1 group would see only
Issue Types relevant to them, and likewise for Project_2. The two
projects could be complete separate, or have some overlap in the
issues they could view. I mention this last point because we
previously abandoned Trac at my place of work because it didn't
support multiple "projects" but I wondered if this could be worked
around using permissions similar to what I have proposed?

I post this hoping to have some helpful advice from the Trac
community. Hopefully Trac can solve my problems and save me some
work, otherwise I'll consider creating my own solution. I also post
because I believe people should attempt to improve an existing project
before blindly starting yet another project, but sometimes new
projects are necessary.

[Daniel Woste]

Hey Devin,

sounds like a great project.

I have some friends, which were looking for a bugtracker with the same keyfeatures like yours.

And they are all using Mantis now:

http://www.mantisbt.org/

It's not written in python (it's php), but its focus is on usability.

In my opinion you shouldn't start a new project, because there are so many well tested bugtrackers available.

Perhaps it is easier to modify an existing one or create a plugin for them.

And even if a bugtracker looks a little bit too complicated, does it really count?

As you already told us, your users will skip not needed fields. But this doesn't cost much time.

2012/4/6 Devin Jacobs <dbutton...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
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.

--

Daniel Woste

Geschäftsführer

useblocks GmbH
Schopenhauerstr. 71
80807 München

Internet: www.useblocks.com
Telefon: 089 / 66 66 17 48

Mobil: 0176 / 23 94 94 96
E-Mail: daniel...@useblocks.com

useblocks GmbH
Geschäftsführung: Marco Banse, Daniel Woste
Sitz der Gesellschaft: München

Registergericht: München, HRB 193131

USt-IdNr. DE 278106025

[Peter Suter]

On 06.04.2012 04:43, Devin Jacobs wrote:
> More telling is that I don't need any features related to programming
> and source code, timelines, roadmaps, a wiki, etc.

All these components can be completely disabled & hidden in Trac:

[components]
trac.versioncontrol.* = disabled
trac.timeline.* = disabled
trac.ticket.roadmap.* = disabled
trac.wiki.* = disabled

> All the issue trackers I'm aware of just have too many features given
> prominent display when they're not needed. Users complain that
> there's 20 fields on the screen and they only ever use 2 or 3.

Trac by default has some fields that can be disabled & hidden simply by
deleting the defaults (Components, Milestones, Priorities, Resolutions,
Severities, Ticket Types and Versions). This results in (depending on
what you count as a field) ~5 fields.

Some plugins allow hiding fields. E.g. SimpleTicketPlugin:

http://trac-hacks.org/wiki/SimpleTicketPlugin

> Users - A user account, email, password, etc. A user interacts with
> the issues they have access (permission) to. A user may have access
> to an issue either directly or through a group membership.

While Trac checks user (and group) permissions per-issue, to specify
per-issue permissions you'd need a plugin. E.g. PrivateTicketsPlugin:

http://trac-hacks.org/wiki/PrivateTicketsPlugin

> Groups - ...

Sounds exactly like Trac to me.

> Issue Types - ...

Trac by default always shows all fields. There are some plugins that
make them depend on the ticket type or permissions:

http://trac-hacks.org/wiki/CondFieldsPlugin
http://trac-hacks.org/wiki/DynamicFieldsPlugin
http://trac-hacks.org/wiki/BlackMagicTicketTweaksPlugin

The plugins maybe don't do exactly what you want, but I think it shows
that Trac is pretty flexible, so if you have the time and know how you
could always write your own plugins.

Hope this helps!

[Leho Kraav]

I think you should take a look at what people are doing with Bloodhound https://incubator.apache.org/projects/bloodhound.html

Obviously whatever patches you can come up with for Trac *or* Bloodhound are always welcome. Just keep in mind all new stuff is a process that affects a lot of people, so nothing is guaranteed to get it and takes a lot of perseverence to polish and finish. I just don't see how rolling your from scratch, by yourself (if that is the case), could get close to what Trac's codebase is today. It takes years and years and power of many men to work all the quirks out and achieve real feature completeness and stability.

So I would definitely encourage you to patch existing work to the max, customize it to your specifics, push applicable stuff upstream. Everybody wins and you get your tool while youre still young. :>

[RjOllos]

On Sunday, May 6, 2012 12:22:45 AM UTC-7, Leho Kraav wrote:

So I would definitely encourage you to patch existing work to the max, customize it to your specifics, push applicable stuff upstream. Everybody wins and you get your tool while youre still young. :>

You just reminded me of this page, which might be useful to him:
http://trac.edgewall.org/wiki/TracDerivatives
I imagine that is just a small list of the projects that have been derived from Trac.