Page 1 of 1

Issues marked 'Resolved' when they're not

Posted: 22 Oct 2020, 20:01
by rajay
I use Mantis to keep track of bugs I report to my developer. Sometimes he marks issues as 'Resolved' but they are not. The problem is, I can't see how to change an issue back to 'Assigned' from 'Resolved'.

If i choose the Change Status dropdown on "View Issue Details", to "Assigned" it takes me to a 'Assign Issue' form but I need to attach an upload, which I can't do from that screen.
If i choose the Reopen button on "View Issue Details" it takes me to a 'Request Feedback on Issue' form. I don't want to request feedback: i need to attach an upload, which I can't do from that screen.
If I press Edit on "View Issue Details", again that screen does not allow uploads.
If I just add a Note onn "View Issue Details", I can upload an attachment but that does not change the status so my developer will never see it.

What am I missing here ?!

Re: Issues marked 'Resolved' when they're not

Posted: 22 Oct 2020, 23:55
by Starbuck
You're talking about Workflow Transitions.
Select the project in the top-right of the tracker. Go to Manage > Manage Configuration > Workflow Transitions.
The grid can be intimidating but it's very simple. Just look at each row/status as "this is where a ticket is now". Then in each column, if a ticket can move to the status for that column, check it, otherwise uncheck it.
So for example, if you do not want a ticket moving from Assigned to Resolved, go down the first column to the Assigned row, then across to the Resolved row, and uncheck it.

You might want to set this based on role. Look under that grid to the next one for Access Levels. You can set the Minimum Access Level that allows a specific status to be assigned. If you do not want any developer to put any ticket in Resolved status, use the dropdown list for that status and change it to Manager.

Note that the role is for a Project. You can set these details for All Projects by changing the project selection at the top. Then each project can override that high-level setting. So you might want all projects to default to allow a Developer role to resolve tickets, but for one project you can set this override so that only Managers can resolve a ticket.

Consider the above to be a guide. Think about your high-level defaults for projects, then for specific projects, then for user roles.

You can also create a new role, for example a Project Leader, that is a copy of all details that apply to Developer but only this role and higher can resolve tickets. Then your developers can remain in the Developer role, except for specific projects that are more sensitive - and you don't need to give anyone Manager role just to allow them to resolve a ticket.

Re: Issues marked 'Resolved' when they're not

Posted: 23 Oct 2020, 00:09
by Starbuck
I have another policy-oriented response to this. I see people resolving tickets at the wrong time too, and it sometimes really annoys me. The question is : What exactly is Resolved?

Is a ticket resolved when the developer finishes coding?
What status should be used after In Progress?
This is where we create additional Status codes and then set them in the workflow transitions.

In some cases, a ticket is not Resolved unless the Reporter says it is. So we need to move from In Progress to something like Testing or QA. This would be for internal testing to verify that the developer completed the task and didn't break anything new. From there it might move to UA Test for user acceptance. This is where the end-user / client / reporter gets notified "we're done and we think it works, but we want You to verify that we did what You think it needs to do". So the client tests it and they confirm the issue is fixed, or maybe it goes back to In Progress. When the client says it's done, you might then need to move it to a new status like Deployment. This is where the new product update is queued for inclusion in file uploads, beta testing, or whatever the next step is.

Now, do we consider the issue "Resolved" when the developer finished working it? When the user verifies it? When it has gone through the Deployment phase? That's entirely up to you and it might be different on a per-project basis. The status codes, roles, and workflow transitions need to be adjusted to suit your business policies and procedures.

I think the best way to approach all of this is to document on paper exactly how your operation flows in business terms. Recreate the workflow transition grid in a spreadsheet. Share it with colleagues to see if they can poke holes in your plan, like "what happens if we need to expedite a patch into the field?" or "what status is it when we are trying to contact someone to test it but they aren't actually testing it yet?"

Then the next step is just to work out the mechanics of how to get MantisBT to exactly follow and facilitate your business policies. The documentation really helps for this, and there are many forum posts here on these topics as well.

Have fun!

Re: Issues marked 'Resolved' when they're not

Posted: 23 Oct 2020, 11:18
by rajay
Very helpful responses - thankyou both !
I never would have figured this out by myself.