0003164: Added "fixed in version" field, set when resolving a bug - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update
0003164	mantisbt	bugtracker	public	2003-05-01 15:19	2024-10-17 05:39

Reporter	AJCartmell	Assigned To	vboctor
Priority	normal	Severity	feature	Reproducibility	always
Status	closed	Resolution	fixed
Product Version	0.18.3
Fixed in Version	0.19.0a1

Summary	0003164: Added "fixed in version" field, set when resolving a bug
Description	We've added a "fixed_release" field to the database, just a VARCHAR. Then we've added an input to allow the project manager to add the release number that includes (or will include) the change. Comes in handy later on when someone else reports the same bug because they're using an old version, or for people deciding whether or not to upgrade. Might possibly link this to the list of release versions, although often the fixed_release value is an as-yet unreleased version.
Tags	No tags attached.

vboctor 2003-05-01 16:25 manager ~0004283	This is a duplicate of 0001179. The custom fields support was designed/implemented to cover such features. You should be able to define a "Fixed in Release" field and provide an enumeration for the possible values. You can also specify the access level required to view/change this field. So you can have VIEWER access level required to view it, and MANAGER access level to set it/modify it. Let me know if that does not cover your needs.

vboctor 2003-05-01 16:37 manager ~0004284	I added "Fixed in Release" custom field to this installation as an example. I think we need it anyway. However, you will only be able to view it. Developers will be able to set it.

AJCartmell 2003-05-01 16:59 reporter ~0004285	Ah yes, custom fields - I keep forgetting they're there. We've only just upgraded from 0.17 since my company has finally admitted defeat with the very-expensive Rational ClearQuest and decided to use Mantis instead! The only minor improvement over a simple custom field would be to prompt the MANAGER to set it when the bug is closed via the close_page. I can see it getting forgotten otherwise (my memory is hopeless!). Perhaps we need another table to allow the set-up of custom fields on some of the various submit/update/resolve/close pages.... - uh oh, looks like Feature Creep! or perhaps the template suggestion is the way to go... [My request isn't quite a duplicate of 0001179 - their requirement is for an indication of which release a bug should be fixed by, whereas mine is for a record of the release in which a bug was fixed. In fact we are thinking about the former too, but this is lower priority for us.]

jfitzell 2003-05-01 18:41 reporter ~0004286	Yes, any time people start talking about custom fields, the features start to creep. I am resisting adding any more functionality to them until we've actually done a stable release and get some more feedback. I wouldn't want it to be some unweildy over-configurable mess.

Hauptmann 2003-08-29 11:00 reporter ~0004581	Of course mantis should not reach into an unconfigurable mess. But using a user field for this purpose makes it very cumbersome for a developer to set a bug to 'fixed'. He has to use 'update bug' to manually change the status to 'fixed' and to set the 'fixed in version' field (if he doesn't forget it). A mandatory field for that in the resolve bug page would make this much more efficient. Evenmore, I think this field should be a build in field and not a user defined field since (imho) everyone needs it and mantis could use it in many ways (in the view all bugs table to make change logs with respect to versions, statistics regarding the software versions etc.)

vboctor 2004-05-24 08:28 manager ~0005572	Implemented in CVS. Will be included in 0.19.0. The implementation details are as follows: This is only in the advanced view/update pages. Included in Resolve Bug page. Included in the print page. Included in CSV export. Not available in report simple/advanced. Not included in Close Bug page.