There's a problem with doing what you're suggesting. Using the "Assign To" and "Change Status To" buttons on the view issue page drives the workflow in Mantis, whereas the update issue page allows you to zap values on a field by field basis without driving the workflow. It's much easier to wind up with inconsistent values in your records if you use the update issue page.

I'd actually like it if the "Status" and "Assigned To" fields were removed from the update issue page so that changes to these fields would be forced to always drive the workflow.

The values in the status and assigned to field are consistent with those on the view page. They do drive the workflow properly.

IMHO, I see that most bugs progress through a workflow primarily using the "Change Status to:" button.

Would graphically groupong these buttons/pulldowns together help? (Note that this is more obvious if you shrink the screen horizontally).

Maybe I'm missing/misinterpreting something here (or misusing the word "workflow"), but...

If I go to the update page for a new issue, change the status to "assigned" and save my changes I wind up with an issue in assigned status and no assignee. However if I use the "Assign To" button on the view page, I have to pick an assignee and wind up with a consistent record.

Similarly, in update I can change the status to "resolved" and not cause any other field to be changed, but if I use the "Change Status To" button on the view page I go through bug_change_status_page which encourages me to supply appropriate values for other fields.

What I meant by "inconsistent values" was, for example, assigned records with no assignee or resolved records with a resolution value of "open". I didn't mean that the view page would show different values than the update page.

Maybe the "Change Status To:" and "Assign To:" buttons should also be provided on the update page so that the same processing occurs for status and assignee when update is used.

I think the UI issue that I originally described is independent of the issue that the bug report could end up in an inconsistent state. If the underlying architecture of Mantis doesn't allow for the UI tweaks I suggested then we should keep my suggestions on ice until the underlying architecture can be changed.

Also, I think the "assigned" status state should be removed. I think all bugs should be assigned at all times. There should be a default assignee for all new bugs for every project or category. The default assignee is responsible for assigning the bug to someone else if necessary. It doesn't make sense to me that a bug can exist that is not assigned. If so, who is responsible for assigning it?

We should think about how to co-design the UI and workflow so that Mantis is intuitive and there is no possibility of inconsistent states.

Regarding: the "resolved records with a resolution value of "open"" inconsistent state. The resolution values have little value in my opinion. I just want to set the status to "resolved" and then describe the resolution in a "resolution" textbox. Currently, I describe the resolution in a note. This is fine, but often just want to know the final resolution.

I've only been using Manitis for a week now. I think I'd give you guys my first impressions.

The fact that it is possible to end up in inconsistent states means that there is redundancy in the UI/workflow that should be cleaned up.

I too would like to be able to enter the Update Issue page by default instead of the View Issue page. Updating many issues in a row is very time consuming!

I'd suggest a new config option as follows:

$g_auto_update_threshold = NOBODY

A typical usage would be to explicitly set it to MANAGER (or even DEVELOPER) either globally or for specific projects. The users at those levels generally edit issues far more often than other users, they understand the Mantis workflow very well and would be able to keep the issue's state consistent.

A better option (but possibly requiring more work) would be to allow users to turn such an option on themselves in their own preferences.

PS - I have played around with this a little by changing string_get_bug_view_url(), one thing that breaks is that the "<<" and ">>" links are not available. This feature from the View Issue page would need to be ported to the Update Issue page.