View Issue Details

IDProjectCategoryView StatusLast Update
0004864mantisbtfilterspublic2020-03-19 16:06
Reportervboctor Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version0.19.0 
Summary0004864: 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.

TagsNo tags attached.

Relationships

related to 0021153 new Filtering Custom Fields with empty values not showing correct value 
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 

Activities

warde06

warde06

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!

ryandesign

ryandesign

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.

warde06

warde06

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!

siebrand

siebrand

2009-06-13 04:24

developer   ~0022136

Unassigned after having been assigned for multiple years without progress.

dhx

dhx

2010-03-12 09:00

reporter   ~0024713

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.

am-gtz

am-gtz

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

vovella

vovella

2013-03-20 03:08

reporter   ~0035921

I have this problem too.

Can't access to patch!

bluescreenterror

bluescreenterror

2020-03-19 16:05

reporter   ~0063779

Hi,

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

Issue History

Date Modified Username Field Change
2004-11-15 08:10 vboctor New Issue
2005-09-16 14:52 warde06 Note Added: 0011381
2005-09-18 09:26 ryandesign Assigned To Narcissus => ryandesign
2005-09-18 10:56 ryandesign Note Added: 0011389
2005-09-18 10:56 ryandesign Status new => feedback
2005-09-19 17:19 warde06 Note Added: 0011395
2005-09-20 10:39 ryandesign Status feedback => acknowledged
2009-06-13 04:24 siebrand Note Added: 0022136
2009-06-13 04:24 siebrand Assigned To ryandesign =>
2009-06-13 04:24 siebrand Status acknowledged => new
2010-03-12 08:57 dhx Relationship added has duplicate 0011476
2010-03-12 09:00 dhx Note Added: 0024713
2010-03-12 09:28 am-gtz Note Added: 0024722
2013-03-19 12:57 atrol Relationship added duplicate of 0015667
2013-03-19 12:57 atrol Relationship replaced has duplicate 0015667
2013-03-20 03:08 vovella Note Added: 0035921
2016-06-24 04:48 atrol Relationship added related to 0021153
2018-01-19 05:46 atrol Relationship added has duplicate 0023852
2020-03-19 16:05 bluescreenterror Note Added: 0063779