[Prev] Thread [Next]  |  [Prev] Date [Next]

[Trac] Can Trac help me build my ideal issue tracking system? Devin Jacobs Fri Apr 06 01:00:12 2012

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

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.

You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at