The list, radio and enum custom field types cannot currently hold a null value. This is why bug_report.php is complaining about the list field having an empty value. Maybe we should allow for null values in these fields and we'll simply print a label like "Undefined" when a value hasn't yet been set?

Sounds OK to me.. printing the label "Undefined", i assume you are talking about the manage custom field page.

FYI:
As far as i can see, in 1.2.0 the fields cannot hold a null value either, but this problem doesn't occur.

i have the very same problem with the version 1.2.1. is there any quick fix or patch?

i tried to find a workaround by supplying default values, but if the user does not have write access he has no chance to report a bug.

I found a workaround: Downgrade to 1.2.0! I believe that these are side effects from 0011628

I have a custom field "Affected versions" defined as "=released_versions". This field is used to signal which versions are affected by a given issue beyond the one the bug is reported against. Given it's declaration, it is difficult to set a default without inserting a dummy release for each project, having NULL values in such fields like lists or enum should be OK - it's a missing value.
And I can confirm this didn't happen in 1.2.0, it started to happen in 1.2.1

Same error here and I'm confused why the field should ever get a NULL value when a default value is defined.

We also encountered this bug after upgrading from 1.1.6 to 1.2.1.

We have a custom Enumeration type No|Yes. Default value No. Required on Report unchecked. Display on Report also unchecked.

The use case is that this enumeration type would default to No and only be set to Yes later by developers. Thus it is not required when reporting.

The workaround for this error message in Mantis 1.2.1 is to check "Display on Report", this serves to populate the custom field with the default value and thus it passes validation. However this is not ideal as reporters have nothing to do with this field.

Could this please be targetted to 1.2.2? It's quite annoying for users, first when they encounter an inability to report an issue, and then again when the Report Issue screen becomes cluttered with custom fields they don't use.

I reported a duplicate of this bug and attached a patch in 0011951.

Thanks Sergiodf. I can confirm the patch in 0011951 worked for me. Hope it gets incorporated in the next Mantis release too.

(perhaps this issue could be updated to block severity and have the patch attached?)

Spoke too soon... After applying the patch I'm seeing a situation where an Enumeration type of No|Yes, default value No, Display Report = no, Required on report = no, is now triggering a different error, which is the second ERROR_CUSTOM_FIELD_INVALID_VALUE instance, ie in the code:

    if( !custom_field_set_value( $t_id, $t_bug_id, gpc_get_custom_field( "custom_field_$t_id", $t_def['type'], '' ), false ) ) {
        error_parameters( lang_get_defaulted( custom_field_get_field( $t_id, 'name' ) ) );
        trigger_error( ERROR_CUSTOM_FIELD_INVALID_VALUE, ERROR );
    }

The issue is still submitted, however the error leads the user to think it wasn't.

I have attached a new patch. I hope this time solves your situation, djcarr.

Here is what I posted to the mailing list:

Many custom field types in MantisBT are sets[1] (mathematics: set
theory). Usually a set can be an empty set[2] and this is true for
certain MantisBT field types including checkbox and multilist. The
problem is that HTML UI controls for enumeration, list and radio field
types do not allow the user to specify an empty set. In other words, the
user is unable to undo their selection of a radio item to make the value
of the field undefined. Once they click on a radio option they're forced
into selecting one of the options even if they no longer want to commit
to any of the choices.

Users should be modifying their custom fields to add a new option
"Undefined" or "Not specified" (or similar terminology to represent an
empty set/null). This null value can then be selected by default on the
bug report page if you want to allow users to easily ignore it when
posting a bug.

However I do NOT recommend adding an "Undefined" option as it is a sign
that you're using the wrong type of field for the wrong task. Radio
fields are meant to contain items that are mutually exclusive where the
user has to select exactly ONE option from the list[3]. In other words,
they're not designed to hold a null value.

List and enumeration fields are basically the same mathematical concept
as the radio field (mutually exclusive options, select exactly one). The
only real difference with these field types is determining which UI
control will be used to present the options to the user.

I do agree that there is a need for a field which is a set of mutually
exclusive options where the user can select either the emtpy set OR one
of the options from the set. However I don't see how we can achieve that
without combining multiple UI field types together (a checkbox to toggle
whether the field is an empty set or not) or using JavaScript to
redefine how UI controls work (this is neither robust or accessible to
users).

[1] http://en.wikipedia.org/wiki/Set_%28computer_science%29

[2] http://en.wikipedia.org/wiki/Empty_set

[3] http://www.useit.com/alertbox/20040927.html

The follow up to my comment on the mailing list was that we need to document things clearer so that administrators understand that the "require" checkbox has no effect on radio/list/enum fields. If the "display" checkbox is not checked on reporting an issue, you MUST provide a default value for the field.

I've assigned this issue to myself and I'll do what I can to make it easier for users to understand.

That's fair enough, but my experience of this issue is that the error still occurs even when you DO provide a default value for the field. Scenario was: "Custom Enumeration type No|Yes. Default value No. Required on Report unchecked. Display on Report also unchecked." - this configuration worked in previous versions, and is a very valid and common end user scenario. So this to me falls under the definition of a regression. I can see from the mailing list that it may be getting confused with the separate logistical issue that occurs when a default value is not provided.

Sergiodf's latest patch does work for me, though I should mention that it simply allows the still-undefined types to proceed through the Report Bug validation. On the Bug View page, the custom fields will have no value (blank). This also probably means they won't obey filters in the way one would expect. It is only once you edit the bug that you will see the custom fields populated with their defaults, and when you save the bug again they are finally persisted.

Is it possible in the Report Bug screen to have hidden fields that populate the undisplayed custom fields with their default values, so that the validation will succeed, AND the default values get stored to the bug?

I don't think hidden fields is a good idea, because you can not trust on http post sent by client (it could have been modified).
But we can get default values from custom field definitions and store that values.

Hi, we have the same prob with 1.2.1. Enum Ja|Nein with Nein as default. No Display on Report, No required on Report. Then we get the error. It only works with: See on Report and the writeAccess to Reporter. The the box showes and Nein ist selected and written to the issue... would be fine to see fixed in next release... store the default to the issue when the user can't access or see the field on the page..

So...
one question:

Why empty multilists work fine in mantis 1.1.8?
I just don't get it :/

part of the patch:
if ( $t_def['require_report']
&& ( $t_def['type'] == CUSTOM_FIELD_TYPE_ENUM
|| $t_def['type'] == CUSTOM_FIELD_TYPE_LIST
|| $t_def['type'] == CUSTOM_FIELD_TYPE_MULTILIST
|| $t_def['type'] == CUSTOM_FIELD_TYPE_RADIO
)
&& !gpc_isset_custom_field( $t_id, $t_def['type'] )
) {
error_parameters( lang_get_defaulted( custom_field_get_field( $t_id, 'name' ) ) );
trigger_error( ERROR_EMPTY_FIELD, ERROR );
}

That makes no sense.
Now you just get the error if the field has no value AND the field is one of the four problem fields. Average custom fields which you define for 'being not empty on report' are ignored.

Why don't you just kill the special fields in the if()?

Somethink like the following works fine for me:
if ( $t_def['require_report']
&& !gpc_isset_custom_field( $t_id, $t_def['type'] )
) {
error_parameters( lang_get_defaulted( custom_field_get_field( $t_id, 'name' ) ) );
trigger_error( ERROR_EMPTY_FIELD, ERROR );
}

Maybe i didn't get it, but that makes more sense to me:)
Thx for the patch btw :)

You are right, crazya. I realized yesterday after hour.

We should consider the special case of CUSTOM_FIELD_TYPE_CHECKBOX, where emptyness is a valid selection.
I had problems with checkboxes before and had to remove al 'required' for custom fields of this type.

New patch: 11684-2.diff
Run against original 1.2.1 file.

Temporary workaround: Add additional value to custom field (eg. "undefined") and set this value as "default value"

Hi, i have the same Problem and found the same code like crazya. I have changed it nearly like crazya but only error message changed to validation error.

This code and also dominiks workaround only works if the field is displayed at reporting :(

Hi, it seems like I have the same issue when updating a issue. Could it be related ?

Yes, highmqn, it is the same problem.
I attach 11684-2-bug_update.diff to patch bug_update.php similar to 11684-2.diff.

This validations should be in a function instead of copied in every file.

Thanks a lot ! Does the problem still appears when the custom field is not displayed ?

Just to be clear does Sergiodf patch resolve this issue?

basically this bug should have the highest possible priority since it basically as made all installations of Mantis 1.2.1 that uses custom fields non functional.

Good morning,

I have just updated our test server with 1.2.2 to check if this issue was fixed and I can reproduce it.

The problem is that we have a Custom Enumeration type called "Test On Site?" that has the values "No|Yes" and a default value "No". The "Required on Report" field is unchecked and "Display When Reporting Issues" is also unchecked.

However when a new issue is raised, the error:

"A necessary field "Test On Site?" was empty. Please recheck your inputs."

is reported. We are still running 1.2.0 after finding the issue in the 1.2.1 release.

Is there a workaround?

Mark Retallack.

PS. thanks for all the hard work that has gone into creating Mantis.

markretallack, you can try applying 11684-2.diff (and eventually 11684-2-bug_update.diff).
No other solutions up to now.

I had this problem after upgrading from 1.2.0 to 1.2.1. I was able to get it working again by modifying the core/custom_field_api.php, bug_report.php and bug_update.php files.

Changes:
core/custom_field_api.php
The validation checks for multilist, enum, list and radio needed changed to allow empty values. This was needed to fix an "invalid data" error after the field required logic was corrected.

Diff (against 1.2.1 release):
1177a1178,1180

      if( $p_value === '' ) {
          break;
      }

1186a1190,1192
if( $p_value === '' ) {
break;
}

bug_update.php
The required field test in 1.2.1 is incorrect and will always return true for custom enum, list, multilist and radio fields. The custom value assignment also needed changed to null (someone please confirm that this won't break anything)
Diff (against 1.2.1 release):
142c142
< ( $tdef['require' . $t_custom_status_label] ||

      $t_def['require_' . $t_custom_status_label] && (

150,151c150
<
< $t_new_custom_field_value = gpc_get_custom_field( "customfield$t_id", $t_def['type'], '' );

  $t_new_custom_field_value = gpc_get_custom_field( "custom_field_$t_id", $t_def['type'], null );

bug_record.php
The same logic error from bug_update.php is present in bug_report.php.

Diff (against 1.2.1 release):
108c108
< ( $t_def['require_report'] ||

       $t_def['require_report'] &&(

@dhx: Selecting empty values in enumerations/lists and deselecting all entries in a multilist are IHMO perfect and valid methods to express an empty set in HTML UI controls. Even mantis makes use of this, e. g. in several version list boxes.

However, I don't see this as an UI issue. If the admin decided that a field isn't required then there's always the possibility of a default NULL/undecided value, and mantis should be able to handle that.

This is an absolute showstopper for us to work with mantis > 1.2.0. We have several enumeration fields that are only required under special circumstances, so the default value is empty - and this doesn't work anymore.

@nimmich: you can't deselect a selection you've made in a combo box (enumeration) or list control. As such you'll need to add an "Unspecified" option to your radio/list/enumeration custom field possible values string. You'll also need to change the default value of the custom field to match the newly added "Unspecified" string. You can then safely turn off the "require" checkbox for certain pages and not worry about the user leaving the field blank (it'll use the default value instead).

You can deselect all options in a multiple-selection list control therefore MantisBT 1.2.x allows null values for the multilist custom field type.

@dhx: By now requiring that a new enumeration entry of "Unspecified" or "Undefined" or whatever be created is firstly not very elegant, and secondly causes a further problem for us.

We have a custom enumeration that is not required or displayed when reporting an issue, but is required when updating it. This is because the value is not known at the time you log the issue, but will be known when you update it later.

If the default value of the enumeration is empty/null, then when you log it, it will not have any value, but when you update it, you will be forced to select a value.

However, if you have a default value of "Unspecified", there will be no way to force the person updating the issue to change that value as it is a valid value and therefore passes the 'required' test. This allows an issue to flow the entire workflow and still have this value set at "Unspecified" because there was no forced requirement to change it.

If an empty or null value was once again allowed (as it was in previous versions) then you would once again be able to only force a value to be populated later in the process.

I would also like to add that even if you use a default value of "Unspecified", this has absolutely no effect when the field is not displayed on the report page. An empty value is still set, which then causes the issue to fail. The only way around this is to display each and every enumeration field on the report page, which unnecessarily clutters up the report page.

macarbiter is right, I can confirm that use case (we have the same in my company's project) and the problem, that now every custom field must be visible on bug submit page, which confuses a lot of users, as they don't know what to enter here.

I am getting this after the upgrade as well. I am currently on 1.2.1.

I have to agree with the last three notes. We are finding this issue is a complete showstopper for updating to the latest Mantis version.
Is there anything we can do to help the development of a fix for this?
Thanks,
Andy

I wonder if we can turn our thoughts to the solution here. My thoughts run along the lines of:

1. When a new issue is submitted, the validation process should first cycle through the displayed fields (which would have been pre-populated with default values anyway, so they are usually going to be valid.)
2. The validation should then cycle through the non-displayed fields and assign default values to them where available
3. Where a default value isn't available, null is accepted as a valid value and the issue allowed to proceed. It doesn't seem feasible to disallow null entirely because there are so many ways that null values can enter Mantis - through imports, db upgrades, adding or removing custom fields, etc. However, Mantis can be designed to be biased against null values so that they don't occur very often.

Hi all,

Sergiodf, there is something missing in you patch. For an empty multiselection list, when modifying a bug, the empty value is forbidden, which does not make sense, because we should be able to select nothing.

There is a small correction to do in custom_field_api.php. I added a new patch, containing both corrections of Sergiodf + the correction in custom field api (to be applied with “patch -p1”).

Hope this will help.

Sometimes there's the need of displaying a combo list for a custom field, which is required, and without a default value, so the user is forced to select one of the items. Even better if it displayed a "select a value from the list" default item (not selectable itself...)

So...i think:
if a "blank" selection is not in the valid items for the selection list, it should not validate.
OR make it as a configuration option for the custom field: "null field is valid selection"
OR adding regexp validation for advanced control (by the way, discarded on 0011610)

I understand that certain types can not store a NULL value. In the other hand if I set a default value to the field I somewhat thought that the default value will be applied.

If the field is assigned to that certain project then it has to be created when the issue is created (with the default value if it is not displayed or not required). Later on let say when the issue is updated the field should show the current value. I dont know how complicated it is to code, but I think this would resolve the problem.

I agree with the comments above, this is a major inconvenience now.

There was a recent commit (for an upcoming 1.2.4 release) recently which should solve a number of problems related to custom fields (especially on the update page). See: http://git.mantisbt.org/?p=mantisbt.git;a=commitdiff;h=76c9a79ef7d88a135e226088c167e90065ef9277

I am currently on 1.2.3
The problem is still happening.

Same here, 1.2.3 and still happening.

This behavior (not accepting null values) makes the flag "required" in the "Manage Custom Fields" section a bit useless. I cannot leave the field empty, so it is the same as I configure the field "required".

Same in 1.3.0 nightly versions.

Is there any indication when this will be fixed or at least a working patch file for 1.2.3 will be available?

We embarked on a process to get Mantis 1.2 rolled out to our whole company after we had been successfully using 1.1 for the last few years. However, this bug has caused a major set-back on this roll-out, and the choice to go with Mantis is starting to be second guessed.

I also noticed this now in our mantis 1.2.3 and this is somewhat a showstopper for us. Have this been planned to be fixed in 1.2.4?

Victor Boctor attached a patch in 0012619 for those who don't like this behavior.

I have added a patch I have done to take care of the problem.

It inserts empty strings in the fields that are declared "NOT NULL", which seems to be sufficient.

@Sergiodf, @dhx and others. I've done a check-in based on a fix that I did before knowing about this issue. When I inspected Sergiodf's patch, I found that he has more changes. Please validate my fix / latest and feel free to provide a patch on top.

I hope that my fix unblocks the majority of the users (if not all). However, if there are other changes that are necessary to completely handle the regression, then let us get it in before 1.2.5 is released.

See the attached changeset (890c36eb) for more details.

@vboctor, thanks for reverting the change of functionality in 1.2.x - I can confirm that your changes look OK.

We can work on improving custom field validation/etc in a later major version of MantisBT.

I tried vboctor's patch but it does not work with custom fields of type "List" having a default value defined but unchecking "Display When Reporting Issues".

In my installation, I have a field where the only boxes checked are "Display When Closing Issues" and "Required On Close" (this field is used only when closing an issue). Using vboctor's patch, it is not possible to submit a new issue.

@Sergiodf, did you apply both my patches? I did a follow up patch soon after the first one that should probably fix the issue you mentioned.

You are right, Victor. I did not apply the "follow up patch".
Now, with both patches, I tried to report an issue and then to update it. It worked in both cases.

Should we mark this issue as resolved then? Any objections? If we are to revisit the change of behavior for 1.3.x, then we should open a new feature request and link to this one.

This issue should be marked as resolved, in my opinion.

We're seeing the same problem in 1.2.4 and a quick check of the attached patch diffs against the source we've installed suggests that the patch didn't make it into the 1.2.4 release.

cjm1, the fixed and target version is set to 1.2.x which means that the fix will be available with next version 1.2.5
If you want this now, you can download a nightly build from www.mantisbt.org/builds

Sorry...my bad. For some reason I missed 1.2.4 being released and as I'd only just seen it assumed it was new in the last few days, rather than being released before the patch became available.

Thanks to vboctor for fixing this issue.

But in one case it hasn't worked very well:
If a custom field was designed with write access for at least developer-level and additionally this field was mandatory for reporting a new issue a
reporter-level user writing a new issue, received an error message, that he has to fill the custom field.

I expanded the patch from vboctor to fix this remaining issue so therefore I hope that the application may now work appropriate.

bug_report.php from line 101 based on master-1.2.x 890c36eb

Validate the custom fields before adding the bug.
$t_related_custom_field_ids = custom_field_get_linked_ids( $t_bug_data->project_id );

foreach( $t_related_custom_field_ids as $t_id ) {
Do not set custom field value if user has no write access.
if (!custom_field_has_write_access_to_project($t_id, $t_bug_data->project_id)) {
    continue;
}

$t_def = custom_field_get_definition( $t_id );
# Produce an error if the field is required but wasn't posted.
if ( !gpc_isset_custom_field( $t_id, $t_def['type'] ) &&
    ( $t_def['require_report'] ) ) {
    error_parameters( lang_get_defaulted( custom_field_get_field( $t_id, 'name' ) ) );
    trigger_error( ERROR_EMPTY_FIELD, ERROR );
}
if ( !custom_field_validate( $t_id, gpc_get_custom_field( "custom_field_$t_id", $t_def['type'], NULL ) ) ) {
    error_parameters( lang_get_defaulted( custom_field_get_field( $t_id, 'name' ) ) );
    trigger_error( ERROR_CUSTOM_FIELD_INVALID_VALUE, ERROR );
}
}
Allow plugins to pre-process bug data
$t_bug_data = event_signal( 'EVENT_REPORT_BUG_DATA', $t_bug_data );
Create the bug
$t_bug_id = $t_bug_data->create();
Mark the added issue as visited so that it appears on the last visited list.
last_visited_issue( $t_bug_id );
Handle the file upload
if ( !is_blank( $f_file['tmp_name'] ) && ( 0 < $f_file['size'] ) ) {

file_add( $t_bug_id, $f_file, 'bug' );

}
Handle custom field submission
foreach( $t_related_custom_field_ids as $t_id ) {
Do not set custom field value if user has no write access.
if( !custom_field_has_write_access( $t_id, $t_bug_id ) ) {
    continue;
}

$t_def = custom_field_get_definition( $t_id );
if (gpc_isset_custom_field( $t_id, $t_def['type'] )) {
    if( !custom_field_set_value( $t_id, $t_bug_id, gpc_get_custom_field( "custom_field_$t_id", $t_def['type'], '' ), false ) ) {
        error_parameters( lang_get_defaulted( custom_field_get_field( $t_id, 'name' ) ) );
        trigger_error( ERROR_CUSTOM_FIELD_INVALID_VALUE, ERROR );
    }
}
}

bug_update.php from line 150 based on master-1.2.x 890c36eb

Don't update the custom field if the new value both matches the old value and is valid
This ensures that changes to custom field validation will force the update of old invalid custom field values
if( $t_new_custom_field_value == $t_old_custom_field_value &&

custom_field_validate( $t_id, $t_new_custom_field_value ) ) {

continue;

}

dissi, please enter a new issue for this problem and attach your patch.
See http://www.mantisforge.org/dev/manual/en/developers/dev.contrib.submit.html#DEV.CONTRIB.SUBMIT.PATCH for the recommended way.