0004687: Closing an item deletes custom-field-value if type of custom-field is CHECKBOX or MULTILIST - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0004687	mantisbt	custom fields	public	2004-10-11 10:10	2004-12-11 03:02

Reporter	RJelinek	Assigned To	grangeway
Priority	normal	Severity	major	Reproducibility	always
Status	closed	Resolution	fixed
Product Version	0.19.0
Fixed in Version	0.19.2

Summary	0004687: 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;
Tags	No tags attached.

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 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 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 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 2004-11-07 17:15 reporter ~0008274	Ok, I believe that this is now fixed in CVS Paul

grangeway 2004-11-07 17:15 reporter ~0008275	oops