View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004864 | mantisbt | filters | public | 2004-11-15 08:10 | 2020-05-19 14:27 |
Reporter | vboctor | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | new | Resolution | open | ||
Product Version | 0.19.0 | ||||
Summary | 0004864: Unable to filter on empty custom field value | ||||
Description | For an enumeration custom field which allows the user to choose a combo box to choose a target release, I wasn't able to filter the issues that have the custom field set to the value of empty string (which is one of the enumeration values). I am only able to filter on "any" or specific values. | ||||
Tags | No tags attached. | ||||
related to | 0021153 | new | Filtering Custom Fields with empty values not showing correct value | |
related to | 0012798 | new | Add a filter option [Something] as opposite of [None] i.e. field not null | |
has duplicate | 0011476 | new | [patch] Make an empty-selection possible for ENUM custom fields | |
has duplicate | 0015667 | closed | atrol | Filter bad work with a blank cell in custom field |
has duplicate | 0023852 | closed | atrol | "None" value not available for Enumeration type of Custom field |
related to | 0008149 | acknowledged | New filter option: [Someone] for Assigned to and other filter fields |
We are using 1.0.0rc1 and this problem seems to still exist. Do you know if there are any plans to fix it or if there might be a workaround? We are using an enumerated custom field set to "=versions" and so we are unable to filter on those that do not have a version set yet. Your help is greatly appreciated! |
|
If you set up a custom enumeration field and set its possible values to "=versions" then, when creating or updating an issue, for this field, you get a drop-down menu containing all the versions for that project. What you don't get is an option to assign none of these versions to that field's value -- you must select one of them. So the only possible way you could have an issue where this field is empty is if the field was added to the project after the issue had already been created, and the issue has not been updated since then (because if you were to update the issue afterwards, the version field would get filled in with something). Am I understanding this right? Is this the situation we're talking about? Is it desirable to have a custom enumeration field showing the project's versions, yet also allow the possibility for the user to select "none of these"? If it is, then that should also be programmed, and would make the request in this issue more relevant, IMHO. |
|
Yes, this is the situation that I am talking about. We have a custom field for Target Version, but it is not required. We were having a problem when someone updated a bug, because if they click the "Update" bug button then it would automatically assign the first version in the list. Since this is not always the correct version, I added a blank as the first value so that it will automatically assign blank unless they select something else. I have created an override function for custom_function_default_enum_versions and added the following line: $t_possible_values = '|'.$t_possible_vales; This part is working fine now, but they are unable to filter on bugs that do not have a version selected yet. We have 1000s of issues already created (Mantis is awesome and we have been using it for several years now), but we just added the target version field with the release of 1.0.0rc1 in the last month or so. So that is why we need the "none of these" option. Thank you for your help! |
|
Unassigned after having been assigned for multiple years without progress. |
|
Alex has provided an updated patch at http://git.mantisforge.org/w/mantisbt/gtz-et.git?a=shortlog;h=refs/heads/mantisbt-issue11476 Not tested yet. I think the "require" flag may be a better approach to deciding whether or not a blank value is allowed for enumeration (and other list-type) fields. |
|
Actually the intention of my patch was a bit different i.e. even for required fields, the (select) value should be included, just the way like this is for Categories and so on. We just do not want to pre-select an existing value to require users to choose the correct values (instead of not touching the drop-down box and thus choosing a wrong value). |
|
I have this problem too. Can't access to patch! |
|
Hi, stumble on this issue in recent Version 2.24.0. Created a pull request on github: https://github.com/mantisbt/mantisbt/pull/1633 |
|
The patch in the previous note matches my need. I posted also a comment on github. For now I have removed the test (core/filter_form_api.php line 1961) on my mantis instance. |
|
I've proposed a pull request on github : https://github.com/mantisbt/mantisbt/pull/1670 |
|