View Issue Details

IDProjectCategoryView StatusLast Update
0004687mantisbtcustom fieldspublic2004-12-11 03:02
ReporterRJelinek Assigned Tograngeway  
PrioritynormalSeveritymajorReproducibilityalways
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
Description

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

Additional Information

Solution:
In gpc_get_custom_field there is a

return '';

This should be changed to

return $p_default;

TagsNo tags attached.

Relationships

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

Activities

grangeway

grangeway

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

RJelinek

RJelinek

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.

RJelinek

RJelinek

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.

grangeway

grangeway

2004-11-07 16:54

reporter   ~0008272

hmm

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.

grangeway

grangeway

2004-11-07 17:15

reporter   ~0008274

Ok, I believe that this is now fixed in CVS

Paul

grangeway

grangeway

2004-11-07 17:15

reporter   ~0008275

oops

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