FeaturesWanted

Michael Bernstein

Here are a few permissions I think are missing from the security interface:

• Add iTrackIssueFollowup
• Change iTrackIssueFollowup

There is also fairly big problem with how iTrack finds people it can assign stuff to. Currently, iTrack lists all users defined in the iTrack folder as being assignable. This is undesireable for two reasons:

• It ignores users defined elswhere in the heirarchy
• It forces dummy users to be created so they will appear in the list

The solution would seem to be to list users that have a certain role, such as iTrackAssignee. This would allow users to be acquired, and eliminate the need for dummy users in the folder. By making this a local role, you could easily let certain users be assignees on one tracker, and others in another tracker.

Shalabh(25-Apr-2000):This is an excellent suggestion. I did want to improve the way iTrack finds people but couldn't think of a good way to do it.

Chris Beaumont

Several things that my computer support workgroup asked for when I proposed using iTrack:

• The option to have issues created by email to a given address in addition to creating them on the web.
• The ability to have iTrack send an email to the submitter acknowledging that an issue had been received and supplying the URL where it's current status could be viewed.
• The ability/option to have an extra hidden field that was only visible to a subset of users for private internal notes.. ("this is the fourth time we've had to fix this!" etc..)
• The option to have a given issue be private (only seen by the submitter and the support staff) or public (so others could see it and learn from it's resolution) Hope my suggestions are helpful..

  Shalabh(27-May-2000) Sorry for the late response. Yes the suggestions are very good. The ability to add issues thru email looks like the toughest one. I don't know if zope has the python modules for pop. Anyone got any good ideas?

  Jace (18-Dec-2000) You wouldn't use POP. You'll then have the issue of scheduling Zope to check for mail every so often. A better method is to write a procmail filter on the bug-report mailbox that calls your method over HTTP. I remember seeing a tool at FreshMeat?.net that can make POST requests (necessary only for multi-line text fields or to hide data from appearing in log files.