View Issue Details

IDProjectCategoryView StatusLast Update
0026539mantisbtcustom fieldspublic2020-02-03 04:35
Reportermnewnham Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version2.22.1 
Summary0026539: Enumeration type of custom fields does not sanitize option input for trailing spaces
Description

The enumeration option allows input of options in the form a|b|c|d, and in the main application presents the option as a select list. However, the option allows for trailing spaces inside of individual options, i.e. 'A|B_|C|D'. Because of the nature of browser formatting and the use of select lists, It is impossible to see that they are in the record. They are however visible in the mantis_custom_field_table.

This causes a problem in the API, as the option must exactly match to pass validation, i.e the passing of value "B" above must be passed as "B__" and the error returned:
{"message":"Invalid value for custom field 'Field1'","code":29,"localized":"Invalid value for 'value'"} obviously provides no assistance as to why the validation failed.

The solution for this is : on save of enum type : explode on "| " -> array_map('trim') -> implode on "|"

This would leave any spaces deliberately left inside the custom fields untouched e.g. |Level 1|Level 2| etc...

TagsNo tags attached.

Activities

dregad

dregad

2020-02-02 17:37

developer   ~0063557

Last edited: 2020-02-03 04:35

View 2 revisions

I can confirm that the system's behavior is as described, i.e. if the enum custom field is defined as a|b |c (b with 2 trailing spaces) then you do need to provide the REST API payload as {"field":{"id":xxx},"value":"b "}

That being said, creating an issue from the GUI and selecting value b from the selection list, does store the custom field's value as b (with 2 trailing spaces) in the database so the system works consistently even though it may be somewhat confusing to the GUI user, who never sees the trailing spaces because the browser does not display them.

The solution for this is : on save of enum type : explode on "| " -> array_map('trim') -> implode on "|"

Do I understand correctly, that you're suggesting to remove leading/trailing spaces when saving the custom field's definition (i.e. in manage_custom_field_update.php / custom_field_update() function?

If so, I am concerned that this might introduce data discrepancies in systems that have custom field values stored with leading/trailing spaces, and some data cleanup would need to take place either as a one-shot upgrade task, or everytime an enum custom field is read/written.

mnewnham

mnewnham

2020-02-02 20:05

reporter   ~0063558

I think that the input should be sanitized.

  1. I cannot imagine that that was not the developers intent.
    a If it had not been, they would have specifically disabled standard end-of-string space removal
    b. They would have provided a method of displaying the trailing spaces.
  2. I understand the possibility of issues with existing data. The next release should
    a. provide an upgrade path that reports and optionally cleans up the current records, both at a master and transactional level. OR
    b. Provides a more robust interface in the custom fields maintenance to specifically allow and show the behavior as well as eliminating the end of field white space truncation.
    c. Possibly a configuration parameter to allow one or the other.

Issue History

Date Modified Username Field Change
2019-12-30 11:39 mnewnham New Issue
2020-02-02 17:37 dregad Status new => feedback
2020-02-02 17:37 dregad Note Added: 0063557
2020-02-02 20:05 mnewnham Note Added: 0063558
2020-02-02 20:05 mnewnham Status feedback => new
2020-02-03 04:35 dregad Note Edited: 0063557 View Revisions