View Issue Details

IDProjectCategoryView StatusLast Update
0020002mantisbtcustom fieldspublic2015-09-13 18:27
Reporterbadfiles Assigned Tovboctor  
Status closedResolutionfixed 
Product Version1.3.0-beta.2 
Target Version1.3.0-beta.3Fixed in Version1.3.0-beta.3 
Summary0020002: Custom field value may not be purged

Setup an 'email' or 'string' type custom field with min_length=max_length=0. Open an issue and give such field a value. Then try changing it with bug_update_page.php. Setting an empty value would do nothing.

With bug_actiongroup_page.php you could set any value, including empty.



has duplicate 0019570 closeddregad Custom Field - Cannot blank the value 




2015-08-23 14:17

manager   ~0051298

I can reproduce this. This bug was introduced as part of a fix for the set of bugs that were introduced when the bug_update.php action page started being used for multiple actions: update issue and change status.



2015-08-23 16:58

manager   ~0051299




2015-08-23 17:33

manager   ~0051300

Another scenario that I included in the pull request is the following:

  • User X has access level necessary to report issues.
  • Custom field C1 requires higher access level to read/write than user X access level.
  • Custom field C1 is required on reporting.
  • User X can't report issues.

The fix is to only require the field if a user has access to set and hence it is rendered in the form.



2015-08-27 05:07

developer   ~0051319

Regarding the scenario described in 0020002:0051300, I am not sure this is a good thing to do, as it essentially defeats the purpose of making the field mandatory when reporting, which may lead to data inconsistencies down the line.

In other words, since C1 is mandatory, you expect to find some value in it, but issues reported by X will have C1 == null.

In my opinion, preventing X from reporting issues in such case is the correct behavior; the appropriate fix is to revise the configuration (lower C1 write access level or increase X's)



2015-09-05 02:02

manager   ~0051375

Follow up fix PR:



2015-09-06 05:32

developer   ~0051378

@vboctor, since you did the root cause analysis, maybe you could update product version from 'git trunk' to the appropriate value.



2015-09-13 18:26

developer   ~0051457

Updated product version based on related issue 0019570

Related Changesets

MantisBT: master 047f5aad

2015-08-27 22:53:35


Details Diff
Fix ability to purge value of a custom field

Fixes 0020002
Affected Issues
mod - bug_update.php Diff File
mod - core/custom_field_api.php Diff File

MantisBT: master ba13782f

2015-09-05 01:30:34


Details Diff
Fix custom field access denied on bug update page

The previous fix caused triggering of access_denied due to the addition of the BUG_UPDATE_TYPE_NORMAL.

Issue 0020002
Affected Issues
mod - bug_update.php Diff File

Issue History

Date Modified Username Field Change
2015-08-04 20:59 badfiles New Issue
2015-08-22 17:12 vboctor Assigned To => vboctor
2015-08-22 17:12 vboctor Status new => assigned
2015-08-23 14:17 vboctor Note Added: 0051298
2015-08-23 16:58 vboctor Note Added: 0051299
2015-08-23 17:00 vboctor Target Version => 1.3.0-beta.3
2015-08-23 17:01 vboctor Severity minor => major
2015-08-23 17:01 vboctor Tag Attached: mantishub
2015-08-23 17:33 vboctor Note Added: 0051300
2015-08-27 05:07 dregad Note Added: 0051319
2015-08-27 22:55 vboctor Changeset attached => MantisBT master 047f5aad
2015-08-27 22:55 vboctor Status assigned => resolved
2015-08-27 22:55 vboctor Resolution open => fixed
2015-08-27 22:55 vboctor Fixed in Version => 1.3.0-beta.3
2015-09-05 02:02 vboctor Note Added: 0051375
2015-09-06 05:32 dregad Note Added: 0051378
2015-09-06 12:24 vboctor Changeset attached => MantisBT master ba13782f
2015-09-06 17:37 vboctoradmin Status resolved => closed
2015-09-13 18:26 dregad Product Version git trunk => 1.3.0-beta.2
2015-09-13 18:26 dregad Note Added: 0051457
2015-09-13 18:26 dregad Relationship added related to 0019570
2015-09-13 18:27 dregad Relationship replaced has duplicate 0019570