Mantis Bug Tracker - Forums

I am trying to implement a custom boolean field, "Resolution Requires Approval," with the following semantics:

• Its value can be either "no" or "yes," represented by a radio button
• When an issue is initially created its (default) value in that issue should be "no"
• Its value can only be changed (i.e., set to "yes") by a user with Manager privilege or higher

However, what I'm seeing is that when a user with Reporter privilege creates an issue, the field is not given a value at all (i.e., it is neither "no" nor "yes"). This would seem to contradict the notion that its default value is "no."

Is this a limitation/bug of MantisBT (i.e., setting any value, even the default, requires Manager privilege)? Or am I just getting something wrong in my configuration? I've included a screen shot of the relevant configs for this custom field as an attachment.

If it is a limitation/bug, is it possible to work around it by either choosing different values for the field (i.e, different from "no|yes") or by using a different type of control (i.e, something other than a radio button)?

Um... okay.

So I dug into the code of bug_report_page.php, and have discovered that basically nothing gets done with any custom field that the reporting user doesn't have 'rw' access to. Such fields are not included in the form (not even as hidden fields) and so there's no trace of them in the POST of that form to bug_report.php.

Even if somehow such a field did get included among the POST variables, there's code in bug_report.php that prevents setting the field's value -- even to the defined default value -- if the reporting user doesn't have write access to the field.

Does this behavior strike anyone other than me as wrong?

It seems to me that a field should be initialized to its default value if no alternative value was provided, regardless of whether the reporting user failed to provide a value or was prohibited from providing a value. If a default value is defined, the field certainly shouldn't be left "floating," with no value, should it?

In my opinion, a more reasonable behavior for restricted-access custom fields in a bug report would be:

• for users with read access but no write access, to display the field pre-set to its default value and with the input control disabled, and to write that default value to the database on submit;
• for users with neither read nor write access, to include the field as a "hidden" input pre-set to the default value, and again, to write that default value to the database on submit.

Comments? Contrary opinions? Should I file a change request?

Hephaestus wrote:Um... okay.

Providing answers in this forum is nearly a one man show.
I can't invest much time for Mantis at the moment.
You can use also one of our other support channels where other developers are listening.
https://www.mantisbt.org/support.php
https://gitter.im/mantisbt/mantisbt

Hephaestus wrote:Should I file a change request?

No time to have a deeper look, this one might be the same or a similar issue https://www.mantisbt.org/bugs/view.php?id=16011
Adding all information what you have discovered will certainly help.

Thank you @atrol for the reply and all the good pointers, and sorry if my comment sounded overly impatient. That was not my intention.

I will add my findings to #16001 as you suggest, and after a bit more time researching the code, I may also submit a PR for that issue.

Hephaestus wrote:I may also submit a PR for that issue.

Submitting a PR would be great.
Please make sure that your submissions adhere to our Coding Guidelines http://www.mantisbt.org/wiki/doku.php/m ... guidelines