View Issue Details Jump to Notes ] Wiki ] Related Changesets ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011684mantisbtcustom fieldspublic2010-03-19 11:182013-10-11 23:23
Assigned Tovboctor 
PlatformOSOS Version
Product Versiongit trunk 
Target Version1.2.5Fixed in Version1.2.5 
Summary0011684: Incorrect error "A necessary field "MyField" was empty. Please recheck your inputs." when submitting new issue
DescriptionWhen creating a new issue i get an application error 11: "A necessary field "my custom field" was empty. Please recheck your inputs.".

This error message is not correct because "Required On Report" was not checked for the corresponding custom field.
Steps To ReproduceI have reproduced this error on "", on an empty database;

1. Logged in as Administrator
2. Created a new project
3. Created a new custom field
4. Linked the custom field to the project
5. Report a new issue -> fill in the required fields -> submit report
6. You get the error "A necessary field "MyCustomField" was empty. Please recheck your inputs.".

See the attached screenshot for the custom field properties.
TagsNo tags attached.
Attached Filespng file icon MantisManageCustomField.png [^] (20,470 bytes) 2010-03-19 11:18

diff file icon 11684.diff [^] (2,821 bytes) 2010-05-27 11:06 [Show Content]
diff file icon 11684-2.diff [^] (2,658 bytes) 2010-06-04 10:38 [Show Content]
diff file icon 11684-2-bug_update.diff [^] (1,561 bytes) 2010-06-30 09:05 [Show Content]
patch file icon bug11684-full.patch [^] (5,221 bytes) 2010-09-27 10:38 [Show Content]
diff file icon custom_field_api.php.diff [^] (1,086 bytes) 2010-12-29 08:57 [Show Content]

- Relationships
related to 0011628closeddhx Error 0001303 / Custom Field (Checkbox) evaluated as mandantory even when it is not 
has duplicate 0011850closeddhx Mantis thinks custom fields are required when "Display When ...." fields are checked 
has duplicate 0011861closedatrol Custom enum field marked as not mandatory is validated as mandatory 
has duplicate 0011869closedatrol error reporting issues if user doesn't have write access to a custom field 
has duplicate 0011881closedatrol Custom field required when reporting issue after upgrade 
has duplicate 0011918closedatrol Can't create new issues since I created a list type custom field 
has duplicate 0011951closedatrol Bug report page ask for custom fields not required nor displayed 
has duplicate 0011957closedatrol Non required field is forced to fill in. 
has duplicate 0012115closedatrol custom field is mandatory, although not configured to be so 
has duplicate 0012137closedatrol Customer Fields causes problems with upgrading 
has duplicate 0012237closedatrol bug of Validate the custom fields 
has duplicate 0012353closedatrol Not requiered custom field got validated on new issue 
has duplicate 0012202closedatrol Cannot update older issues after upgrading from 1.1.0 to 1.2.1. Get APPLICATION ERROR #11 
has duplicate 0012550closedatrol custom field required, but not configured as required 
has duplicate 0012572closedatrol Multiselection custom field is required even when marked to not be 
has duplicate 0012619closedvboctor Custom fields are reported as required after upgrade from 1.1.0 to 1.2.3 
has duplicate 0012753closedatrol Enumerate custom fields always required 
related to 0013406closeddregad Default values for custom fields are not written to database 
related to 0016020resolveddregad Port Fix of 0011684 to master branch 

-  Notes
User avatar (0024821)
dhx (reporter)
2010-03-19 11:28

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?
User avatar (0025003)
david_s_nl (reporter)
2010-04-02 17:12

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

As far as i can see, in 1.2.0 the fields cannot hold a null value either, but this problem doesn't occur.
User avatar (0025261)
pramsent (reporter)
2010-04-26 05:26
edited on: 2010-04-26 05:30

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

User avatar (0025265)
pramsent (reporter)
2010-04-26 06:59

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.
User avatar (0025267)
pramsent (reporter)
2010-04-26 08:52

I found a workaround: Downgrade to 1.2.0! I believe that these are side effects from 0011628
User avatar (0025355)
ldsandon (reporter)
2010-04-30 11:29

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
User avatar (0025478)
jurgenhaas (reporter)
2010-05-11 15:35

Same error here and I'm confused why the field should ever get a NULL value when a default value is defined.
User avatar (0025526)
djcarr (reporter)
2010-05-17 20:34

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.
User avatar (0025539)
djcarr (reporter)
2010-05-19 01:49

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.
User avatar (0025585)
Sergiodf (reporter)
2010-05-21 17:53

I reported a duplicate of this bug and attached a patch in 0011951.
User avatar (0025592)
djcarr (reporter)
2010-05-23 20:23
edited on: 2010-05-23 20:26

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?)

User avatar (0025615)
djcarr (reporter)
2010-05-26 22:43
edited on: 2010-05-26 23:03

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.

User avatar (0025619)
Sergiodf (reporter)
2010-05-27 11:07

I have attached a new patch. I hope this time solves your situation, djcarr.
User avatar (0025625)
dhx (reporter)
2010-05-29 10:51

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

[1] [^]

[2] [^]

[3] [^]
User avatar (0025626)
dhx (reporter)
2010-05-29 10:54

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.
User avatar (0025628)
djcarr (reporter)
2010-05-30 19:05
edited on: 2010-05-30 19:07

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.

User avatar (0025629)
djcarr (reporter)
2010-05-30 19:58
edited on: 2010-05-30 20:16

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?

User avatar (0025630)
Sergiodf (reporter)
2010-05-30 22:39

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.
User avatar (0025661)
xbromy (reporter)
2010-06-02 08:59

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..
User avatar (0025679)
crazya (reporter)
2010-06-03 09:56

one question:

Why empty multilists work fine in mantis 1.1.8?
I just don't get it :/
User avatar (0025701)
crazya (reporter)
2010-06-04 09:01
edited on: 2010-06-04 09:02

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 :)

User avatar (0025704)
Sergiodf (reporter)
2010-06-04 09:40

You are right, crazya. I realized yesterday after hour.
User avatar (0025705)
Sergiodf (reporter)
2010-06-04 09:44

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.
User avatar (0025707)
Sergiodf (reporter)
2010-06-04 10:39

New patch: 11684-2.diff
Run against original 1.2.1 file.
User avatar (0025962)
dominik (reporter)
2010-06-23 07:54

Temporary workaround: Add additional value to custom field (eg. "undefined") and set this value as "default value"
User avatar (0025989)
icksde (reporter)
2010-06-29 03:44

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 :(
User avatar (0025999)
highmqn (reporter)
2010-06-30 07:34

Hi, it seems like I have the same issue when updating a issue. Could it be related ?
User avatar (0026000)
Sergiodf (reporter)
2010-06-30 09:05

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.
User avatar (0026001)
highmqn (reporter)
2010-06-30 09:45

Thanks a lot ! Does the problem still appears when the custom field is not displayed ?
User avatar (0026004)
tps123 (reporter)
2010-06-30 14:56

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.
User avatar (0026173)
markretallack (reporter)
2010-07-30 03:48

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.
User avatar (0026179)
Sergiodf (reporter)
2010-07-30 11:53

markretallack, you can try applying 11684-2.diff (and eventually 11684-2-bug_update.diff).
No other solutions up to now.
User avatar (0026208)
bbogovich (reporter)
2010-08-03 18:58

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.

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):
> if( $p_value === '' ) {
> break;
> }
> if( $p_value === '' ) {
> break;
> }

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):
< ( $t_def['require_' . $t_custom_status_label] ||
> $t_def['require_' . $t_custom_status_label] && (
< $t_new_custom_field_value = gpc_get_custom_field( "custom_field_$t_id", $t_def['type'], '' );
> $t_new_custom_field_value = gpc_get_custom_field( "custom_field_$t_id", $t_def['type'], null );

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

Diff (against 1.2.1 release):
< ( $t_def['require_report'] ||
> $t_def['require_report'] &&(
User avatar (0026213)
nimmich (reporter)
2010-08-04 13:31

@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.
User avatar (0026246)
dhx (reporter)
2010-08-09 05:37

@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.
User avatar (0026428)
macarbiter (reporter)
2010-08-23 16:48

@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.
User avatar (0026429)
macarbiter (reporter)
2010-08-23 17:12

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.
User avatar (0026440)
KarlReichert (reporter)
2010-08-24 03:34

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.
User avatar (0026469) (reporter)
2010-08-25 10:07

I am getting this after the upgrade as well. I am currently on 1.2.1.
User avatar (0026470)
picochip (reporter)
2010-08-25 11:24

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?
User avatar (0026472)
djcarr (reporter)
2010-08-25 19:16

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.
User avatar (0026873)
sveyret (reporter)
2010-09-27 10:42

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.
User avatar (0027006)
cproensa (reporter)
2010-10-11 08:12
edited on: 2010-10-11 08:14

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)

User avatar (0027201)
istvanb (reporter)
2010-10-30 06:31

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.
User avatar (0027202)
dhx (reporter)
2010-10-30 09:10

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:;a=commitdiff;h=76c9a79ef7d88a135e226088c167e90065ef9277 [^]
User avatar (0027369)
llattan (reporter)
2010-11-15 15:55

I am currently on 1.2.3
The problem is still happening.
User avatar (0027451)
dandjo (reporter)
2010-11-22 11:26

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".
User avatar (0027452)
dandjo (reporter)
2010-11-22 11:42

Same in 1.3.0 nightly versions.
User avatar (0027486)
macarbiter (reporter)
2010-11-25 04:21

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.
User avatar (0027566)
andy778 (reporter)
2010-12-07 09:54

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?
User avatar (0027643)
dhx (reporter)
2010-12-18 20:44

Victor Boctor attached a patch in 0012619 for those who don't like this behavior.
User avatar (0027748)
z00l00k (reporter)
2010-12-29 08:58

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.
User avatar (0027861)
vboctor (administrator)
2011-01-09 03:11

@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.
User avatar (0027862)
dhx (reporter)
2011-01-09 03:34

@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.
User avatar (0027871)
Sergiodf (reporter)
2011-01-10 12:52

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.
User avatar (0027872)
vboctor (administrator)
2011-01-10 13:06

@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.
User avatar (0027873)
Sergiodf (reporter)
2011-01-10 14:03

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.
User avatar (0027874)
vboctor (administrator)
2011-01-10 15:23

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.
User avatar (0027877)
Sergiodf (reporter)
2011-01-10 15:55

This issue should be marked as resolved, in my opinion.
User avatar (0028082)
cjm1 (reporter)
2011-01-26 03:56

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.
User avatar (0028083)
atrol (developer)
2011-01-26 04:19

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
User avatar (0028084)
cjm1 (reporter)
2011-01-26 04:28 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.
User avatar (0028260)
dissi (reporter)
2011-02-20 11:01

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)) {
    $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' ) ) );

# 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 ) ) {

    $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 
if( $t_new_custom_field_value == $t_old_custom_field_value &&
    custom_field_validate( $t_id, $t_new_custom_field_value ) ) {
User avatar (0028261)
atrol (developer)
2011-02-20 11:14

dissi, please enter a new issue for this problem and attach your patch.
See [^] for the recommended way.

- Related Changesets
MantisBT: master-1.2.x 890c36eb
Timestamp: 2011-01-09 08:00:44
Author: vboctor
Details ] Diff ]
Issue 0012619: Custom fields are reported as required after upgrade from 1.1.0 to 1.2.3.
Issue 0011684: Incorrect error "A necessary field "MyField" was empty. Please recheck your inputs." when submitting new issue.

There is a lot of details about this issue in issue 0011684. In 1.2.1 a breaking change was introduced which blocks users from submitting / updating issues for projects with certain custom field configurations. The aim of this fix is to unblock these users. We can do follow up fixes to improve on this for 1.2.x or to come up with the alternative strategy for 1.3.x. The goal is to come up with an approach that doesn't break existing users. The worst thing is that users upgrade and then find out that they can continue to use the product. If there is a path for upgrade to avoid these issues, then we should automate it as part of the upgrade script.

I haven't marked the issue as completely fixed until dhx checks it out, since he was working on the issue. I've used my fix for 0012619 + one more fix for the update code path. When I compared my fix to the attached patches, I note that the patches have more changes to handle things like special cases for checkboxes and the case where user doesn't have read-write. We may incorporate these after we do the necessary validations. Thanks for Sergiodf for contributing the patches.
mod - bug_report.php Diff ] File ]
mod - bug_update.php Diff ] File ]
mod - core/custom_field_api.php Diff ] File ]
MantisBT: master-1.2.x 7ab6eb38
Timestamp: 2011-01-09 08:23:07
Author: vboctor
Details ] Diff ]
Follow up fix for:

    Issue 0012619: Custom fields are reported as required after upgrade from 1.1.0 to 1.2.3.
    Issue 0011684: Incorrect error "A necessary field "MyField" was empty. Please recheck your inputs." when submitting new issue.
mod - core/custom_field_api.php Diff ] File ]
MantisBT: master 3d969053
Timestamp: 2013-06-20 01:31:29
Author: dregad
Details ] Diff ]
Fix 0016020: allow empty required custom fields

This is a port of the following 1.2.x commits:
- 890c36eb616cf5f1d115efa8b5de61b8b737937a
- 7ab6eb383a29a73ad65ade7de504d45477c87fb3

See related issues 0012619, 0011684 for details
mod - bug_report.php Diff ] File ]
mod - core/custom_field_api.php Diff ] File ]

- Issue History
Date Modified Username Field Change
2010-03-19 11:18 david_s_nl New Issue
2010-03-19 11:18 david_s_nl File Added: MantisManageCustomField.png
2010-03-19 11:28 dhx Note Added: 0024821
2010-04-02 17:12 david_s_nl Note Added: 0025003
2010-04-26 05:26 pramsent Note Added: 0025261
2010-04-26 05:30 pramsent Note Edited: 0025261 View Revisions
2010-04-26 06:59 pramsent Note Added: 0025265
2010-04-26 07:36 pramsent Sponsorship Added pramsent: US$ 10
2010-04-26 07:36 pramsent Sponsorship Total 0 => 10
2010-04-26 08:52 pramsent Note Added: 0025267
2010-04-26 11:37 dhx Relationship added has duplicate 0011850
2010-04-28 08:19 atrol Relationship added has duplicate 0011861
2010-04-30 11:29 ldsandon Note Added: 0025355
2010-05-03 02:22 atrol Relationship added has duplicate 0011869
2010-05-04 07:22 atrol Relationship added has duplicate 0011881
2010-05-11 15:35 jurgenhaas Note Added: 0025478
2010-05-17 20:34 djcarr Note Added: 0025526
2010-05-19 01:49 djcarr Note Added: 0025539
2010-05-21 10:52 atrol Relationship added has duplicate 0011918
2010-05-21 17:53 Sergiodf Note Added: 0025585
2010-05-21 18:33 atrol Relationship added has duplicate 0011951
2010-05-23 20:23 djcarr Note Added: 0025592
2010-05-23 20:26 djcarr Note Edited: 0025592 View Revisions
2010-05-25 06:30 atrol Relationship added has duplicate 0011957
2010-05-25 06:53 atrol Severity minor => major
2010-05-25 06:53 atrol Status new => confirmed
2010-05-25 06:53 atrol Target Version => 1.2.2
2010-05-26 22:43 djcarr Note Added: 0025615
2010-05-26 23:02 djcarr Note Edited: 0025615 View Revisions
2010-05-26 23:03 djcarr Note Edited: 0025615 View Revisions
2010-05-27 11:06 Sergiodf File Added: 11684.diff
2010-05-27 11:07 Sergiodf Note Added: 0025619
2010-05-29 10:51 dhx Note Added: 0025625
2010-05-29 10:54 dhx Note Added: 0025626
2010-05-29 10:55 dhx Assigned To => dhx
2010-05-29 10:55 dhx Status confirmed => assigned
2010-05-30 19:05 djcarr Note Added: 0025628
2010-05-30 19:06 djcarr Note Edited: 0025628 View Revisions
2010-05-30 19:07 djcarr Note Edited: 0025628 View Revisions
2010-05-30 19:58 djcarr Note Added: 0025629
2010-05-30 19:58 djcarr Note Edited: 0025629 View Revisions
2010-05-30 20:16 djcarr Note Edited: 0025629 View Revisions
2010-05-30 22:39 Sergiodf Note Added: 0025630
2010-06-02 08:59 xbromy Note Added: 0025661
2010-06-03 09:56 crazya Note Added: 0025679
2010-06-04 09:01 crazya Note Added: 0025701
2010-06-04 09:02 crazya Note Edited: 0025701 View Revisions
2010-06-04 09:40 Sergiodf Note Added: 0025704
2010-06-04 09:44 Sergiodf Note Added: 0025705
2010-06-04 10:38 Sergiodf File Added: 11684-2.diff
2010-06-04 10:39 Sergiodf Note Added: 0025707
2010-06-06 03:58 oelgebaly Note Added: 0025711
2010-06-07 05:34 oelgebaly Note Deleted: 0025711
2010-06-23 07:54 dominik Note Added: 0025962
2010-06-28 05:53 atrol Relationship added has duplicate 0012115
2010-06-29 03:44 icksde Note Added: 0025989
2010-06-30 07:34 highmqn Note Added: 0025999
2010-06-30 09:05 Sergiodf Note Added: 0026000
2010-06-30 09:05 Sergiodf File Added: 11684-2-bug_update.diff
2010-06-30 09:45 highmqn Note Added: 0026001
2010-06-30 14:56 tps123 Note Added: 0026004
2010-07-19 16:48 atrol Relationship added has duplicate 0012137
2010-07-29 10:41 jreese Target Version 1.2.2 => 1.2.3
2010-07-30 03:48 markretallack Note Added: 0026173
2010-07-30 11:53 Sergiodf Note Added: 0026179
2010-08-03 18:58 bbogovich Note Added: 0026208
2010-08-04 13:31 nimmich Note Added: 0026213
2010-08-05 04:05 atrol Relationship added has duplicate 0012237
2010-08-09 05:37 dhx Note Added: 0026246
2010-08-23 16:48 macarbiter Note Added: 0026428
2010-08-23 17:12 macarbiter Note Added: 0026429
2010-08-24 03:34 KarlReichert Note Added: 0026440
2010-08-25 10:07 Note Added: 0026469
2010-08-25 11:24 picochip Note Added: 0026470
2010-08-25 19:16 djcarr Note Added: 0026472
2010-09-14 10:55 jreese Target Version 1.2.3 => 1.2.4
2010-09-15 08:52 atrol Relationship added has duplicate 0012353
2010-09-27 10:38 sveyret File Added: bug11684-full.patch
2010-09-27 10:42 sveyret Note Added: 0026873
2010-10-11 08:12 cproensa Note Added: 0027006
2010-10-11 08:14 cproensa Note Edited: 0027006 View Revisions
2010-10-17 14:35 atrol Relationship added has duplicate 0012202
2010-10-30 06:31 istvanb Note Added: 0027201
2010-10-30 09:10 dhx Note Added: 0027202
2010-11-15 15:55 llattan Note Added: 0027369
2010-11-22 11:18 atrol Relationship added has duplicate 0012550
2010-11-22 11:26 dandjo Note Added: 0027451
2010-11-22 11:42 dandjo Note Added: 0027452
2010-11-25 04:21 macarbiter Note Added: 0027486
2010-11-30 15:16 atrol Relationship added has duplicate 0012572
2010-12-07 09:54 andy778 Note Added: 0027566
2010-12-14 21:05 jreese Target Version 1.2.4 => 1.2.5
2010-12-18 20:41 dhx Relationship added has duplicate 0012619
2010-12-18 20:44 dhx Note Added: 0027643
2010-12-25 04:00 dhx Relationship added related to 0011628
2010-12-29 08:57 z00l00k File Added: custom_field_api.php.diff
2010-12-29 08:58 z00l00k Note Added: 0027748
2011-01-09 03:06 vboctor Changeset attached => MantisBT master-1.2.x 890c36eb
2011-01-09 03:11 vboctor Note Added: 0027861
2011-01-09 03:24 vboctor Changeset attached => MantisBT master-1.2.x 7ab6eb38
2011-01-09 03:34 dhx Note Added: 0027862
2011-01-10 12:52 Sergiodf Note Added: 0027871
2011-01-10 13:06 vboctor Note Added: 0027872
2011-01-10 14:03 Sergiodf Note Added: 0027873
2011-01-10 15:23 vboctor Note Added: 0027874
2011-01-10 15:23 vboctor Assigned To dhx => vboctor
2011-01-10 15:55 Sergiodf Note Added: 0027877
2011-01-10 16:21 vboctor Status assigned => resolved
2011-01-10 16:21 vboctor Fixed in Version => 1.2.5
2011-01-10 16:21 vboctor Resolution open => fixed
2011-01-26 03:56 cjm1 Note Added: 0028082
2011-01-26 04:19 atrol Note Added: 0028083
2011-01-26 04:28 cjm1 Note Added: 0028084
2011-02-08 05:47 atrol Relationship added has duplicate 0012753
2011-02-20 11:01 dissi Note Added: 0028260
2011-02-20 11:14 atrol Note Added: 0028261
2011-04-05 14:23 jreese Status resolved => closed
2011-10-20 05:56 dhx Relationship added related to 0013406
2013-06-06 06:39 atrol Relationship added related to 0016020
2013-10-11 23:23 dregad Changeset attached => MantisBT master 3d969053

MantisBT 1.2.17 [^]
Copyright © 2000 - 2014 MantisBT Team
Time: 0.4883 seconds.
memory usage: 3,660 KB
Powered by Mantis Bugtracker