View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005553||mantisbt||bugtracker||public||2005-05-02 03:25||2019-12-03 06:15|
|Summary||0005553: Status Resolved should not be the end of issue tracking. Status Closed should really be the end.|
When in "My View", the summary list of issues is shown under "Assigned to Me (Unresolved)". Only pre-Resolved issues are shown on the list. Issues post-Resolved are not shown at all.
I don't think it's right. After being Resolved, an issue can go through stages such as Tested or Released, etc. until it is finally Closed. At each stage post-Resolved, the issue can be assigned to a different person until it's Closed. Ideally, under "My View", I want to see all issues assigned to me - except for the closed issues.
"Resolved" should not be treated as the end of the bug cycle. If anything, "Closed" should be the unambiguous end of the cycle.
The same problem exists more pronouncedly when one clicks on "Change Status To:" from the View mode. One can change assignee before "Resolved", but however cannot assign to anyone after the issue has been resolved (again, as if "Resolved" is the end of the bug cycle).
I assume you will suggest the use of $g_bug_resolved_status_threshold in config to change this behaviour. But the said config parameter also controls other things relating to Resolved issues (for example, when an issue can be reopened).
|Tags||No tags attached.|
You should explore the new release....
At the top of the page you can set thresholds that affect workflow, the second one is "Status where an issue is considered resolved".
Thanks. I will give the new release a try.
By the way, how do I pay for my little contribution. Payment is not advertised anywhere. Shouldn't the Sponsor button be linked to a payment site?
There are two thresholds. $g_bug_resolved_status_threshold ("status where issue is considered resolved" in the config page) is where the bug is considered resolved. The other is $g_bug_readonly_status_threshold ("status where issue becomes read-only" in the config page. The "read-only" limit was added to prevent an issue from being editted by meer mortals once the issue has reached a certain threshold.
If you set both of these to closed, it should have the desired effect. The only side effect would be that the "reopen" button won't show up intil the issue was closed.
Thanks for your prompt reply. I know I can fiddle with $g_bug_resolved_status_threshold. However, it's the side effect (not being able to reopen until closed) that's undesirable to me.
Besides, I wish to raise the design issue in that Mantis seems to assume that new assignee is not necessary after the bug is resolved (as per $g_bug_resolved_status_threshold).
I would argue that that premise is incorrect because, until the bug is closed, it can ,for all intents and purposes, be assigned to any new handler.
The status CLOSED should be the only threshold to determine whether a bug no longer requires new assignee - rather than whatever is set on $g_bug_resolved_status_threshold.
By the way, would the new release take care of this problem. And also by the way, how do I pay?
Many thanks indeed.
The reopen button is just a shortcut back to a particular status ("feedback" by default). The path from resolved to feedback is normally valid all the time.
There is also nothing to stop the bug from being re-assigned after it has passed the read-only state, by someone with $g_update_readonly_bug_threshold access level.
I think that we can make some improvements to the business logic behind the statuses and access levels required to make changes.
With respect to sponsorships, one of the developers will get in touch with you after the release where the issue is resolved. Payment is usually through PayPal.
See the post below which explains how sponsorships work:
From the business point of view, REOPEN is more than just changing the bug's status back to a previous value. It is most of the time an indication that a developer's fix has been rejected, which Mantis has correctly implemented as an action after RESOLVED.
If you agree with my analysis that every status (standard or customised) needs a handler before the bug is closed, then there are 2 places where fixes are required: "My View" and "Change Status To:".
I suggest the fixes be as follows on the current release 1.0.0a2:
The fix is to list outstanding issues currently assigned to me on "My View" (rather than limited to before RESOLVED).
The language string $s_my_view_title_assigned should be 'Assigned To Me' (rather than 'Assigned To Me (Unresolved)').
There should not be any config parameter to abstract CLOSED for the above logic. It's because every status before CLOSED need a handler (with the exception of _NEW where the handler is optional).
The fix is allow, when clicking on the "Change Status To:" button, to assign to a new handler at any status before the bug is closed.
Again, there's no need to abstract the statsus CLOSED in a config parameter.
In addition to the above, I think there's a problem in bug_change_status_page.php in that, Resolution is always default to FIXED, regardless of its original value. FIXED should be the default only when the original Resolution is OPEN or REOPENED. In other cases, the default should be the original value (e.g. 'not a bug', 'unable to duplicate', etc.) that a previous handler may have entered. The suggested fix is below:
EDIT (dregad) markdown
The first two points could be fixed in your installation by setting $g_bug_resolved_status_threshold to CLOSED. Leaving $g_bug_readonly_status_threshold at RESOLVED will show the re-open button at the resolved status.
The last point has been fixed in CVS.
Thanks for your reply. I think we're going in a circle with regard to this issue. Perhaps I haven't explained myself well enough.
Assuming in a typical workflow I've got the following statuses:
I set $g_bug_resolved_status_threshold to RESOLVED so that my testers can reopen bugs. No problems. All works perfectly.
But the REAL problem is that on "My View", testers cannot see any bugs assigned to them for testing. Ditto the Release Manager. This is because "My View" is currently designed to show unresolved bugs whose statuses < RESOLVED. Thus only developers can use "My View". Testers and Release Manager can't use this feature on Mantis. Why not?
Surely, it should go without saying that all participants shoud see outstanding bugs assigned to them on "My View" - rather than just developers.
I argue that it's a bug in Mantis.
In 0006093, I added two new reports (Issues awaiting feedback, and issues that are resolved that I should check).
I'm referring specifically to the "Assigned To Me" report under "My View". It's a nifty feature. A user looks at that and knows exactly his/her To Do list - without having to go to the full length of "View Issues".
As I said, by design, currently the "Assigned To Me" report can only be used by developers. My testers have complained to the effect that, "Are testers of the world lesser mortals than developers? Is this a discrimination or not :-)?".
Over to you.