View Issue Details

IDProjectCategoryView StatusLast Update
0004687mantisbtcustom fieldspublic2004-12-11 03:02
ReporterRJelinek Assigned Tograngeway  
Status closedResolutionfixed 
Product Version0.19.0 
Fixed in Version0.19.2 
Summary0004687: Closing an item deletes custom-field-value if type of custom-field is CHECKBOX or MULTILIST

closing an item deletes value of custom field, if the type of the custom field is CHECKBOX or MULTILIST

Additional Information

In gpc_get_custom_field there is a

return '';

This should be changed to

return $p_default;

TagsNo tags attached.


has duplicate 0004735 closedthraxisp Loose Custom fields when resolved 
child of 0004818 closedvboctor Mantis 0.19.2 release 




2004-10-12 14:22

reporter   ~0007997

hmm, this must have changed since we merged the resolve/close/update buttons into a single page.

I seem to remember originally we needed it to return '' else it would be impossible to 'unset' a multilist custom field if it had a default value.

i.e. if custom field type was multilist, and default as 2. Going to update a bug, unchecking '2', so nothing was selected, and then saving would fail.

if that case still works, I'll commit this now..



2004-10-13 00:38

reporter   ~0008004

Well, I am not sure about this aspect and I will have to test it.
I think I can do that on 10-15-04.



2004-10-16 02:47

reporter   ~0008071

Ok, I have tested it, and it will be a problem...

The behaviour of 0.19.0 is, that you can uncheck any items of a CHECKBOX or MULTILIST-field although it was already checked, but you leave the information when closing the item (this is this bug I have reported).

With the changing I supposed in the "additional information"-field the behaviour is different. You will not loose the field-value any more, but you can not uncheck all CHECKBOX or MULTILIST-field values, because it the new value will be the default you entered in the custom-field-description.

In the moment I don't know how to solve the problem with losing both possibilities. I think my solution above is important to include, because it is better to avoid to loose any information.



2004-11-07 16:54

reporter   ~0008272


What i'm guessing we could do, is only update ther custom field if it's set to be shown in the edit page for the operation in question.

i.e. if display_close is false, and your closing a bug, don't update that custom field.



2004-11-07 17:15

reporter   ~0008274

Ok, I believe that this is now fixed in CVS




2004-11-07 17:15

reporter   ~0008275


Issue History

Date Modified Username Field Change
2004-10-11 10:10 RJelinek New Issue
2004-10-11 16:56 vboctor Relationship added child of 0004297
2004-10-12 14:22 grangeway Note Added: 0007997
2004-10-13 00:38 RJelinek Note Added: 0008004
2004-10-16 02:47 RJelinek Note Added: 0008071
2004-10-18 18:01 grangeway Assigned To => grangeway
2004-10-19 11:41 thraxisp Relationship added has duplicate 0004735
2004-11-06 05:55 vboctor Relationship added child of 0004818
2004-11-06 05:55 vboctor Relationship deleted child of 0004297
2004-11-07 16:54 grangeway Note Added: 0008272
2004-11-07 17:15 grangeway Status new => closed
2004-11-07 17:15 grangeway Note Added: 0008274
2004-11-07 17:15 grangeway Fixed in Version => 0.19.2
2004-11-07 17:15 grangeway Status closed => resolved
2004-11-07 17:15 grangeway Resolution open => fixed
2004-11-07 17:15 grangeway Note Added: 0008275
2004-12-11 03:02 vboctor Status resolved => closed