View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0011610 | mantisbt | custom fields | public | 2010-03-04 04:36 | 2021-01-11 16:17 |
Reporter | Giovanny Temgoua | Assigned To | dhx | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.1.8 | ||||
Target Version | 1.2.1 | Fixed in Version | 1.2.1 | ||
Summary | 0011610: 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 ); I dodn't understand why such a simple correction haven't been fixed since... | ||||
Tags | No tags attached. | ||||
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. |
|
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)$/". |
|
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! |
|
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. |
|
@Giovanny Temgoua |
|
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. |
|
MantisBT: master-1.2.x b7b9537d 2010-03-04 06:31 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 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 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 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 |