I don't understand.

There is no such thing as a default empty value for the status... it always has to be defined. I see no benefit in clearing the field by default either.

Can you provide more explanation/reasoning?

Thanks

On status list box(Enumeration) by default it always print the next status of the progress. I'm thinking there shell be some kind of default (select) printing and then the user can open the list and select the specific status.

What do you think?

I don't like the idea of having unselectable options in a <select> box. It sounds confusing from a usability perspective.

I quite like the idea of defaulting the <select> value to something that may be useful to the user such as the next highest status that is available for them to select. This would allow one-click status changing in cases where the default value we've selected ends up being the option the user is most likely going to select.

Exactly my point.

I understand this bug report now. However what you're suggesting won't work.

We shouldn't be placing the current status in the list as it makes no sense to change the status to the current status.

At the moment we select the lowest available status as the default option. I'll see if I can change it so that it tries to select the next highest available.

OK I've improved it as per the updated description of this bug.

Committed to 1.3.x and backported to 1.2.x as well.

thumbs up to this change

1) Concerning the current patch

I am confused. I expected until now that the status I configure on manage_config_workflow_page.php in the workflow as a default value is selected there?

2) Addition to the original report (that seems to have been changed a bit)

In our Mantis installation, the managers often required the user interface to required selections on drop down boxes. If there is a default value, the user might mistakenly choose this as the next status. if the default is a (select) option that can not be selected, the user is forced to select the correct next status.

My report was completely different form this.

• What I reported was to required selection on drop down boxes.
  If the default value is the next highest status the user can change the status mistakenly to the default value. To remove this confusion give default value (select) and it's force the user to open the list and select the right status.

@davidinc, would you be so kind as to walk me through an example?

With the change, while viewing an assigned issue, the 'resolved' state is default (displayed) in the drop down for 'change status to'.

I guess before this change 'new' would have been the one selected/default/displayed.

This is how we imagine this feature:

1. I open the bug_view_page
2. In the drop down box it says (select) for "change status to:"
3. So the User can open the drop down box and select the right status of the
   progress.
   Because: The Reason is user can select the right status of the progress not the
   next highest status of default status.

A (select) option is redundant because the user needs to push a submit button before the form is sent. It's not like the status will ever change without the user explicitly making that change. This change was all about making it a little quicker (on average) for users to change the status of an issue.

Ok you are right I think it useful to the user to print the default value of next highest status.
Anyway it's possible to configure the default value in workflow Threshold.
Small confusion ok.
good work on the patch consider it as Resolved.
Thanks!

If I understand correctly, the initial request was to merge the button "Change Status To:" with the options for the button (the drop down containg new, feedback, acknowledged, assigned, resolved, closed)?

I like the change as is (whether it resolves your original request is a different matter) in that a) it can save a click ;) and more often than not probably will, but moreover b)it helps to provide a better feel/flow while using mantisbt

but given the description in 0011729:0025048, I have the impression you mean 'correcting' the status previously entered rather than changing the status in a way that was seen as transitioning from one to the next.

yw84ever, I am a colleague of davidinc.

For clarification:

What our enduser requested was to avoid confusion between the dropdownbox of statuses and the current status of an issue.

In our installation for this department, we removed a fair amount of fields from the view-bug-page using the mange-configuration feature of mantis. Unfortunately we also removed the "Status" field so the users where thinking

Change status to: resolved

means actually the current status is resolved.

We finally got that and added the Status field -- so it should be fine.

The funny part is, that this lead to a totally different improvement of mantis ...

Next time we will post our reports in mother tongue (for example Amharic) to avoid confusion :-) ... just kidding.

Greetings from Ethiopia,
Alexander

=== C L O S E D ===

@am-gtz,

the funny part is, ...

sure did: http://www.mantisbt.org/blog/?p=90

congrats :)

and thanks for the explanation. knowing that mantis was stripped in your application of it helped me understand what was initially meant and why that would be an issue