View Issue Details

IDProjectCategoryView StatusLast Update
0020002mantisbtcustom fieldspublic2015-09-13 18:27
Reporterbadfiles Assigned Tovboctor  
PrioritynormalSeveritymajorReproducibilityalways
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
Description

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.

Tagsmantishub

Relationships

has duplicate 0019570 closeddregad Custom Field - Cannot blank the value 

Activities

vboctor

vboctor

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.

vboctor

vboctor

2015-08-23 16:58

manager   ~0051299

PR: https://github.com/mantisbt/mantisbt/pull/635

vboctor

vboctor

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.

dregad

dregad

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)

vboctor

vboctor

2015-09-05 02:02

manager   ~0051375

Follow up fix PR: https://github.com/mantisbt/mantisbt/pull/638

dregad

dregad

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.

dregad

dregad

2015-09-13 18:26

developer   ~0051457

Updated product version based on related issue 0019570

Related Changesets

MantisBT: master 047f5aad

2015-08-27 18:53

vboctor


Details Diff
Fix ability to purge value of a custom field

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

MantisBT: master ba13782f

2015-09-04 21:30

vboctor


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
0020002
mod - bug_update.php Diff File