Hi all,
We are running mantis for the JVCL and some developers often forget to set the value of the "Fixed in version" field.
I can filter the list of issues to only show those that are marked as fixed and have no "version" set, but how can I update all those issues so that the field is set to a given value?
I could go inside the database and fiddle with the values myself, but I'm wondering if there is a way to do that. I saw the "Select all" check box and the associated combo, but I could not find a way to do what I want with this.
Thanks in advance for your help.
Cheers
Olivier
Mass updating "Fixed in version" value
Moderators: Developer, Contributor
Hear, hear.
One of our dev groups does not know the version number until the day they build it (don't ask me; I didn't tell them to do it that way), so they can't mark the verison number because it doesn't even exist in the bugbase yet.
So I have to go into all their bugs and set the fixed-in version manually.
It would be nice if there was some way for a build system to tell Mantis "For project <so-and-so> add version <such-and-such>". A simple faked POST call would work.
If I wrote that and got it working, would Mantis folks consider adding it in?
One of our dev groups does not know the version number until the day they build it (don't ask me; I didn't tell them to do it that way), so they can't mark the verison number because it doesn't even exist in the bugbase yet.
So I have to go into all their bugs and set the fixed-in version manually.
It would be nice if there was some way for a build system to tell Mantis "For project <so-and-so> add version <such-and-such>". A simple faked POST call would work.
If I wrote that and got it working, would Mantis folks consider adding it in?
You can always define a "Next Release" version that developers should assign fixed issues to. Once the release gets a name and is released, you rename "Next Release" to "Whatever", and then add a new "Next Release".
In some cases when I had multiple branches, I've added "Next 1.x Release" and "Next 2.x Release". This way the developer can indicate the branch on which the issue was fixed.
As for setting the "Fixed in Release" for multiple issues, you can go to the "View Issues" page and scroll to the end. You will find a combo-box for group actions followed by ok button. You should select the issues you want to action, select "Update Fixed in Release" from the combobox, and click OK. This will allow you to set them all to the version number.
Regards,
Victor
In some cases when I had multiple branches, I've added "Next 1.x Release" and "Next 2.x Release". This way the developer can indicate the branch on which the issue was fixed.
As for setting the "Fixed in Release" for multiple issues, you can go to the "View Issues" page and scroll to the end. You will find a combo-box for group actions followed by ok button. You should select the issues you want to action, select "Update Fixed in Release" from the combobox, and click OK. This will allow you to set them all to the version number.
Regards,
Victor
Hi, just thought I'd offer our experience. We started off trying the "Next Release" version approach however we had two main problems (1) several developers working in different branches and there was no guarantee a fix would actually be in the Next Release, and (2) testers could not easily filter issues they could actually test, because issues marked "Resolved" were appearing in their filters too early.
Our solution was to add two custom statuses :
ASSIGNED[, REPAIRED, DELIVERED], RESOLVED, CLOSED
We found this to be more intuitive. The idea being that when a developer fixes the issue, they "repair" it. When they merge it to the release or main branch, they deliver it (optional, we actually skip this step a lot). And finally, when a release is built, it's a single bulk operation to set all the repaired/delivered issues to Resolved with the correct version number. Both developers and testers happy :)
Our solution was to add two custom statuses :
ASSIGNED[, REPAIRED, DELIVERED], RESOLVED, CLOSED
We found this to be more intuitive. The idea being that when a developer fixes the issue, they "repair" it. When they merge it to the release or main branch, they deliver it (optional, we actually skip this step a lot). And finally, when a release is built, it's a single bulk operation to set all the repaired/delivered issues to Resolved with the correct version number. Both developers and testers happy :)
djcarr, I like that. I'm running it past my other QAEs and the software engineers and web developers. I wasn't too keen on the next_version idea because I can't sort the order of version numbers in the popup list.
BTW, I discovered the constant g_show_product_version today. When set to ON in config_inc.php, it lets developers set the version number as they resolve a bug. It was AUTO, but that didn't work for me.
BTW, I discovered the constant g_show_product_version today. When set to ON in config_inc.php, it lets developers set the version number as they resolve a bug. It was AUTO, but that didn't work for me.