We have a breakage in backward compatibility as far as custom field validation/required is concerned.  I've attached a possible patch to the bug and a detailed description of the issue.  We can go with this patch or revert to the definition of "mandatory" for the 1.1.0 release which would be safer.

---------- Forwarded message ----------
From: Mantis Bug Tracker <noreply@mantisbt.org>
Date: Sat, Dec 18, 2010 at 2:40 PM
Subject: [mantisbt 0012619]: Custom fields are reported as required after upgrade from 1.1.0 to 1.2.3
To: vboctor@gmail.com



The following issue has been SUBMITTED.
======================================================================
http://www.mantisbt.org/bugs/view.php?id=12619
======================================================================
Reported By:                vboctor
Assigned To:                vboctor
======================================================================
Project:                    mantisbt
Issue ID:                   12619
Category:                   custom fields
Reproducibility:            have not tried
Severity:                   minor
Priority:                   high
Status:                     assigned
======================================================================
Date Submitted:             2010-12-18 17:36 EST
Last Modified:              2010-12-18 17:36 EST
======================================================================
Summary:                    Custom fields are reported as required after upgrade
from 1.1.0 to 1.2.3
Description:
For a project that had associated non-required custom fields, once the MantisBT
instance is upgraded to 1.2.3, the users started getting errors that a required
custom field was not provided.  The reason for that is the change of definition
of required custom fields between the two versions:

1.1.0 - a required custom field is one that is marked as required.
1.2.3 - a required custom field is one that is marked as required OR is of type
LIST or is of type MULTISELECT LIST or is of type RADIO or is of type ENUM.

The problem in this case is that the project had custom field of type LIST.  The
custom field was configured to not be visible on the report page.

We could fix this issue by reverting back to the 1.1.0 definition, but we can
also attempt to go with the following definition:

1. A custom field is required if it is required or of type ENUM / RADIO
2. List / MultiSelect List are allowed to be empty.

Ideas are welcome.  The goal is to find a setup that makes sense going forward,
but also doesn't break backward compatibility.
======================================================================

Issue History
Date Modified    Username       Field                    Change
======================================================================
2010-12-18 17:36 vboctor        New Issue
2010-12-18 17:36 vboctor        Status                   new => assigned
2010-12-18 17:36 vboctor        Assigned To               => vboctor
======================================================================