These are notes about further development of iTrack. They are mostly snips from email conversations between me and other people (mostly Michael Bernstein) about iTrack.

Please don't hesitate to post your comments to the Wiki. If don't have a lot to write, it might be a better idea to post to the mailing list. Even if you put your ideas in the wiki, please send a note to the list (people don't check the wiki very often).

Contents

• The Big Plan
• Features
• Bugs

The 'Big Plan'

Some of the plans are outlined in the Readme. (Section 4 - Future: The ToDo list)

The 'big' thing in it is the last point on the list, elaborated here:

Current Configurability

Currently only a limited set of attributes are allowed for each issue (type, assignedTo, status etc) and the valid values of some attributes are configurable (type and status).

Planned Configurable Rules

I plan to have the set of possible attributes (and list of possible values etc) configurable through the web. The semantics of the information provided by the admin user could be something like:

This is only the semantics, not the syntax. Something similar to the properties form might be used here, for example.

The user would be able to add, delete or modify this configuration by editing the iTrackConfig object. This makes it somewhat like a ZClass.

Validation Rules

Another feature would be to let the admin user specify 'validation rules'. This would be a way to check that the operation specified by the (normal) user is valid. For example, it could enforce that only a users of a certain group can change the state from 'new' to 'open'. This could be implemented in a number of ways - provide hooks that are called for validation and let the admin user write code to do the dirty work, provide some way for the admin user to specify validation criteria along with other configuration etc.

Validation Rules could also specify what options are visible to a user. Thus a workflow could be build from writing some such rules.

Configurable Views

Having the attribute set configurable necessitates that the views be configurable as well. The admin user could configure a set of default views (list of issues, views of individual issues). The lists could be grouped, filtered and sorted on various criteria. The (initiated) normal users could create thier own views in addition to the ones defined by the admin. This is where I'm hoping to use ZTopics. The views would be stored in the iTrackConfig object too.

Decoupled Backend and Rules

One thing I'd like to bring out is that this mechanism effectively decouples the 'business rules' from the basic tracker facilities. Any configured iTrackConfig object contains all the business rules for A Particular Issue Tracker. Two different iTrackConfig objects created by two different people could actually be two very different issue trackers. Exporting and importing objects being easy in Zope, this allows for people to make their 'iTrackConfig' objects available for anybody else who wants similar features from an issue tracker.

The iTrack Product + iTrackConfig A = Issue Tracker A with features x,y,z.
The iTrack Product + iTrackConfig B = Issue Tracker B with features a,b,c.

The features are now assocaited with this one neatly distributable package. The underlying tracker framework remains the same. Btw, I also plan to launch it on sorceforge.

Features

These are requests I have received from people. Some of these may be taken care of the the 'big plan' above.

Michael Bernstein:

• It seems that there is a permission missing from the permission list: ChangeiTrackIssues. That way, you could assign the permission to a role, and control who can edit issues.
• Implement this as a PTK product, so you can use wizards for creating issues, add a reviewing process, and so you can filter on 'reviewed' status.
• Add a 'Category' property so you can divide issues by category.
• Use ZTopics (http://www.zope.org/Members/MikeP/Products/ZTopic) to build the various views of issues.
• I think that an issue should also have an importance/priority/severity field.
• When you view an issue, you should be able to click through to child issues and then edit them.
• You should be able to re-parent child issues (either as top level issues, or as a child of some other issue). Note: This particular feature is one that I see a need for 'in the abstract', and not something that I _currently_ need.
• Move the manage_addform to an editable DTML method.
• Allow Followups to Followups.(low priority)
• Place the issues and followups into an 'Issues' tab or folder
• Enable a tree view of issues and followups from the management interface.
• It would be nice if the whole thing were unified into a single product with an 'issues' tab(like Squishdot's 'postings' tab).

Jaime:

• It seems that issue are created at the top level. Does this mean that if I have hundreds of issues, they would all live at the top level directory? Can I put them somewhere else (sub folder) Also, if they were in a sub folder, you could have a tree structure to represent issues with parents.
• A property specifying how much of an issue has been completed (0-100%).

Shalabh:

• Another feature I would want is auto-triggered change. For example, an issue with urgency 'normal' would change to 'high' automatically 2 weeks after the issue was created. Of course, this should be configurable.

Bob Corriher:

• When anyone accesses the folder it does not ask for authorization until you access the Issues by AssignedTo method and then it won't accept any of the users from the User Folder. It will accept the superuser id and password.

Michael Bernstein:

• There is currently no way to edit the text in an issue after it has been submitted.
• Authorization fails when trying to examine followups from the management interface.

Please post your comments to the iTrack Future Wiki.