View Issue Details

IDProjectCategoryView StatusLast Update
0011610mantisbtcustom fieldspublic2021-01-11 16:17
ReporterGiovanny Temgoua Assigned Todhx  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version1.1.8 
Target Version1.2.1Fixed in Version1.2.1 
Summary0011610: Regular expressions to validate custom list field
Description

When the user type an regular expression for an enum custom field, the validation is not taken into account.

Additional Information

How to fix :

In the field custom_field_api.php, ligne 971, for the case CUSTOM_FIELD_TYPE_ENUM, just copy/paste the line :

$t_valid &= ereg( $t_valid_regexp, $p_value );
break;

I dodn't understand why such a simple correction haven't been fixed since...

TagsNo tags attached.

Relationships

related to 0011628 closeddhx Error 0001303 / Custom Field (Checkbox) evaluated as mandantory even when it is not 
related to 0025619 confirmed $g_limit_email_domains impacts custom e-mail fields, which is unexpected from its documentation 

Activities

atrol

atrol

2010-03-04 05:36

developer   ~0024628

At first sight I see no usecase for this, which might be the reason why no one entered an issue for this until now and there is no fix for it.
Can you give an example of enum values and regular expression where you use it?

Giovanny Temgoua

Giovanny Temgoua

2010-03-04 05:45

reporter   ~0024629

Well, i have a case where i want a behavior similar to the one of the semection of a category.

You have a list a category and an additionnal option (select). You have to select one of the attributes appart of (select) to validate the values. Actually if you have something like :

Choice1|Choice2|Choice3

Choice1 is selected by default. I change it to (select)|Choice1|Choice2|Choice3

and add the regular expression "/^(select)$/".

dhx

dhx

2010-03-04 06:46

reporter   ~0024632

I think you're misunderstanding the ENUM custom field type... it's a field where the user has to select an option from a list of options provided to them. The user doesn't get to make their own new values.

As an aside, the ereg() function is deprecated and you should use preg_replace() instead.

However saying all of that, you have identified a huge problem - MantisBT doesn't validate the values of many of the custom field types. I've fixed that in a patch I just put together for the 1.2.x and 1.3.x branches. Thanks for raising this issue!

I have tested my new patch briefly and it appears to be working fine. However I'd appreciate it if you could also test it to ensure it works for you as well. If there are any further problems, feel free to reopen this bug report (or make a separate bug report).

Thanks again for your help in improving MantisBT!

Giovanny Temgoua

Giovanny Temgoua

2010-03-04 07:02

reporter   ~0024633

I don't think that a misunderstood the usage of the field. The idea is not to let user make their own values, which is, impossible because the Listbox is not editable...

The idea is to display all the options but add a new one which is not a selectable option. Thus, obtaining the same behavior as the selection of a category (an extra option - select- is added to the list of categories)...

With your patch, there are, in my point of view, no improvement because you check to see if the value is in the array of possible values, which will be always the case because you can not edit the Listbox.

I want to suggest another improvement, but maybe i will need to open a new bug ? Add a group number attributes to the custom field type CUSTOM_FIELD_TYPE_CHECKBOX so that you can have a set of checkbox with only one selectable at a time.

You are right for the usage of preg_replace thought. I forgot that it's now deprecated.

Thanks.

atrol

atrol

2010-03-08 11:21

developer   ~0024672

@Giovanny Temgoua
you can have this without any regular expression
set your enum to
|Choice1|Choice2|Choice3
and set your field to required

dhx

dhx

2010-03-12 07:45

reporter   ~0024708

I'm confused... the enum field type doesn't even print in HTML as an editable selection box. This behaviour is at least consistent with the MySQL definition of the ENUM type:

"An ENUM is a string object with a value chosen from a list of allowed values that are enumerated explicitly in the column specification at table creation time."

We shouldn't be validating an enum field against a regular expression because all the possible values of the enum field are already known. The user can't select any different/new/unexpected values for the field.

Related Changesets

MantisBT: master-1.2.x b7b9537d

2010-03-04 06:31

dhx


Details Diff
Fix 0011610: Validate all custom field types

MantisBT was only validating certain custom field types. List/checkbox
style field values were not being validated making it possible for
malicious users to bypass the custom field 'possible values' setting and
set custom field values to be whatever they desired.

All custom field types are now validated to ensure that selected values
are within the bounds of the 'possible values' setting of each custom
field.

This patch also fixes the radio custom field type so that it no longer
behaves like a field with multiple possible values. Only one value can
be specified for a radio field, hence there is no need to treat it like
an array within gpc_api.
Affected Issues
0011610
mod - core/gpc_api.php Diff File
mod - core/cfdefs/cfdef_standard.php Diff File
mod - core/custom_field_api.php Diff File

MantisBT: master aa2742da

2010-03-04 06:31

dhx


Details Diff
Fix 0011610: Validate all custom field types

MantisBT was only validating certain custom field types. List/checkbox
style field values were not being validated making it possible for
malicious users to bypass the custom field 'possible values' setting and
set custom field values to be whatever they desired.

All custom field types are now validated to ensure that selected values
are within the bounds of the 'possible values' setting of each custom
field.

This patch also fixes the radio custom field type so that it no longer
behaves like a field with multiple possible values. Only one value can
be specified for a radio field, hence there is no need to treat it like
an array within gpc_api.
Affected Issues
0011610
mod - core/gpc_api.php Diff File
mod - core/custom_field_api.php Diff File
mod - core/cfdefs/cfdef_standard.php Diff File

MantisBT: master 375a337d

2010-03-12 06:42

dhx


Details Diff
Various custom field validation, filtering and performance fixes

This commit is a roll-up of various bug fixes related to custom field
implementations within MantisBT. In particular, multilist, checkbox and
radio fields now work as expected when creating and updating bug reports
as well as upon filtering on these custom field types.

Fix 0011628: Checkbox custom field should allow no selections
Fix 0011561: Reimplement an earlier patch to improve performance
Fix 0011610: Reimplement custom field validation logic (see 0011628)
Affected Issues
0010482, 0011561, 0011610, 0011628
mod - api/soap/mc_issue_api.php Diff File
mod - core/custom_field_api.php Diff File
mod - core/cfdefs/cfdef_standard.php Diff File
mod - bug_update.php Diff File
mod - bug_report.php Diff File
mod - core/filter_api.php Diff File

MantisBT: master-1.2.x bbe690f3

2010-03-12 06:42

dhx


Details Diff
Various custom field validation, filtering and performance fixes

This commit is a roll-up of various bug fixes related to custom field
implementations within MantisBT. In particular, multilist, checkbox and
radio fields now work as expected when creating and updating bug reports
as well as upon filtering on these custom field types.

Fix 0011628: Checkbox custom field should allow no selections
Fix 0011561: Reimplement an earlier patch to improve performance
Fix 0011610: Reimplement custom field validation logic (see 0011628)
Affected Issues
0010482, 0011561, 0011610, 0011628
mod - bug_report.php Diff File
mod - core/custom_field_api.php Diff File
mod - api/soap/mc_issue_api.php Diff File
mod - bug_update.php Diff File
mod - core/cfdefs/cfdef_standard.php Diff File
mod - core/filter_api.php Diff File