Re: [phpBT-dev] New optional features (request for comments)

[Ben C. <php...@be...>]

On Sat, Apr 13, 2002 at 04:01:36PM +0200, Jirka Pech wrote:
> I want to start adding new features before all the translations. Features
> needed by me, are (1) Environemnt tracking, (2) Bug closing version
> tracking, (3) External bug id tracking. I think now it's right time to
> discuss these features, I'll explain it:
> 
> (1) Environment tracking means that users will be able to track the
> environment (e.g. Beta testing, Limited production etc.) application is
> running in. I know that we have Version, but it's insufficient. Here is an
> example: Let's have one application, which is running on Testing site. The
> same application is running in separated Limited production (usually called
> 'pilot') environment. Some bugs may appear in version 1.5 only in Limited
> production environment, but these bugs will never appear on Testing site
> which has the same version, but something may be set up differently. The bug
> may appear due to stricter user rights settings or something similar, for
> example. When developers will be able to track that the bug appeared only in
> Limited production, they will have less work to track it. I hope this will
> be usefull per project option.

This does sound good, but I want to have a discussion on how we can add
other lookups like this and the database version of the phpBB guys in a
modular fashion.  How can we make it so that anyone who has something
extra they want to track in the database can just add a new table with
values (let's say phases of the moon for example) and then tie the bug
table to the phases_of_moon table?  I'm thinking of something like the
skeleton script that helps you get started writing a php extension.  It
generates the header, c, and test files that you can use as a jumping
off point for writing an extension.  Perhaps we could write a skeleton
script that creates a db-changes file (alter the bug table, create the
new lookup table, etc.).   I guess the first thing to do is have a
detailed outline of all the changes that need to be made to the code
base and database to have a new lookup, such as Environment, added and
trackable.  Let's try and do this in a modular fashion rather than just
adding more and more lookups.

> 
> (2) Bug closing version is planned to be the Version number, where the bug
> is fixed or where it will be fixed. Bug closing version may be submitted
> when the bug status is changing to Closed or Verified, I'm not sure yet. We
> will put one of next planned versions number into this field. It's similar
> to External bug id, but the Bug closing version will be selected from
> version_name field in TBL_VERSION. This is already planned into release
> 0.9.0.

The version_to_be_closed and the version_closed fields (should those be
the actual names of the new fields?) should act just like the current
version_id field.  They should be foreign keys referencing the version
table.

> 
> (3) External bug id tracking means that we will have one more varchar field
> in TBL_BUG. This (same as previous two) can be per project confuguration
> option. It's needed when you have too many people contributing and some of
> them using other bug tracking system. They need to add their bug tracking
> system's bug id to phpBugTracker and they usually want to be able to search
> by it or filter the search by it.

John put his request in the RoadMap (thanks for using it, guys!) for an 
additional project field that would store a project number or contract number.
His request is very similar to this one -- basically a free-form field that 
can store anything.  I propose we create an extra_info field that is a varchar 
or text that can be labeled anything you like in the UI.

> 
> I'll do all of these in 3 weeks and I want to start as soon as possible, so
> tell me if I'm thinking about it somehow wrong.
> Jirka Pech