View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0016011 | mantisbt | custom fields | public | 2013-06-05 05:19 | 2019-09-17 08:07 |
Reporter | mneute | Assigned To | |||
Priority | normal | Severity | major | Reproducibility | always |
Status | new | Resolution | open | ||
Summary | 0016011: Readonly custom fields and default value | ||||
Description | A custom enumeration field with a default value is working correctly when the user can edit it. | ||||
Tags | No tags attached. | ||||
related to | 0026151 | new | Custom fields required but not displayed should be filled with the default value |
See https://www.mantisbt.org/forums/viewtopic.php?f=2&t=23750 for an analysis of this behavior as it manifests when reporting a bug. I have not yet performed a similar analysis for other phases of the bug lifecycle. In short, the problem is that if the user does not have read/write access to the custom field, the code that populates the bug report page with custom fields simply skips it rather than creating an HTML control with its "disabled" attribute set. See: https://github.com/mantisbt/mantisbt/blob/f67ec45972ada6ef3cf3b727b41ce1afb967ff6c/bug_report_page.php#L566 This not only prevents the field from being displayed, but also prevents it from being initialized to its specified default value when the form is submitted. This particular problem is compounded by the code at https://github.com/mantisbt/mantisbt/blob/f67ec45972ada6ef3cf3b727b41ce1afb967ff6c/bug_report.php#L218 which skips any value submitted for the field, rather than setting it to its specified default value. |
|
We have the same issue here with custom fields are not initally populated. |
|
+1 on this being an issue that's impacted our desired workflow setup. We're currently working around it by just having to expose the fields to more users than we wanted and documenting how they're supposed to be used but it's pretty frustrating |
|