View Issue Details

IDProjectCategoryView StatusLast Update
0004864mantisbtfilterspublic2020-05-19 14:27
Reportervboctor Assigned To 
Status newResolutionopen 
Product Version0.19.0 
Summary0004864: Unable to filter on empty custom field value

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.

TagsNo 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 closedatrol Filter bad work with a blank cell in custom field 
has duplicate 0023852 closedatrol "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 




2005-09-16 14:52

reporter   ~0011381

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!



2005-09-18 10:56

reporter   ~0011389

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.



2005-09-19 17:19

reporter   ~0011395

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!



2009-06-13 04:24

developer   ~0022136

Unassigned after having been assigned for multiple years without progress.



2010-03-12 09:00

reporter   ~0024713

Alex has provided an updated patch at;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.



2010-03-12 09:28

reporter   ~0024722

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).



2013-03-20 03:08

reporter   ~0035921

I have this problem too.

Can't access to patch!



2020-03-19 16:05

reporter   ~0063779


stumble on this issue in recent Version 2.24.0. Created a pull request on github:
Minor changes as far as I can see, please review. thx



2020-04-15 11:04

reporter   ~0063841

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.
In my opinion, the "none" value for filter should always be available.
Some users would even like to have the "not empty" value available but it might have more impact on the code.



2020-05-19 09:09

reporter   ~0064002

I've proposed a pull request on github :
It covers a few issues concerning the filter :
Unable to filter on empty custom field value
New filter option: [Someone] for Assigned to and other filter fields
Add a filter option [Something] as opposite of [None] i.e. field not null