Page 1 of 1

Applying custom fields to existing issues

Posted: 29 Oct 2010, 11:49
by istvanb
I have created a new custom field. If I create a new issue then the field is there, everything is all right. The existing issues also have this new field, but without the default value (I understand this from coding standpoint). Is there a way to force the default value to all the existing issues?

Re: Applying custom fields to existing issues

Posted: 29 Oct 2010, 12:51
by istvanb
OK... so these things are stored in the 'mantis_custom_field_string_table'

there is only a sql command has to be executed which assigns a value to all the issues. I am not that experienced in SQL. I can do it one by one, but is there anybody who can give me a command which performs this. I will execute it thru XAMPP so it can not be a stored procedure.

Re: Applying custom fields to existing issues

Posted: 29 Oct 2010, 13:25
by istvanb
MANTIS 1.2.3

I have difficulties use the custom field:

If the write access is "developer" then no matter if the "display when reporting issues" is checked or unchecked the field wont appear on the issue reporting page which is GOOD. But now a user with a reporter credentials can not report an issue because when the user presses the submit button he got the following error message, even if the "required on report" is unchecked:

APPLICATION ERROR #11 A necessary field "Include to weekly status report" was empty. Please recheck your inputs.

any ideas?

Re: Applying custom fields to existing issues

Posted: 29 Oct 2010, 14:35
by daryn
This problem is due to changes to custom fields to comply with Math Set Theory. Fields which cannot be deselected are required by their nature. The patch below is a hack which circumvents this by only validating the field if it was selected for display on the page. This is NOT supported by MantisBT.

Code: Select all

diff --git a/bug_report.php b/bug_report.php
index 5745659..bb5dc99 100644
--- a/bug_report.php
+++ b/bug_report.php
@@ -148,20 +148,22 @@ helper_call_custom_function( 'issue_create_validate', array( $t_bug_data ) );
 $t_related_custom_field_ids = custom_field_get_linked_ids( $t_bug_data->project_id );
 foreach( $t_related_custom_field_ids as $t_id ) {
 	$t_def = custom_field_get_definition( $t_id );
-
-	# Produce an error if the field is required but wasn't posted
-	if ( !gpc_isset_custom_field( $t_id, $t_def['type'] ) &&
-		( $t_def['require_report'] ||
-			$t_def['type'] == CUSTOM_FIELD_TYPE_ENUM ||
-			$t_def['type'] == CUSTOM_FIELD_TYPE_LIST ||
-			$t_def['type'] == CUSTOM_FIELD_TYPE_MULTILIST ||
-			$t_def['type'] == CUSTOM_FIELD_TYPE_RADIO ) ) {
-		error_parameters( lang_get_defaulted( custom_field_get_field( $t_id, 'name' ) ) );
-		trigger_error( ERROR_EMPTY_FIELD, ERROR );
-	}
-	if ( !custom_field_validate( $t_id, gpc_get_custom_field( "custom_field_$t_id", $t_def['type'], NULL ) ) ) {
-		error_parameters( lang_get_defaulted( custom_field_get_field( $t_id, 'name' ) ) );
-		trigger_error( ERROR_CUSTOM_FIELD_INVALID_VALUE, ERROR );
+	# only validate if it's been displayed on the form
+	if( $t_def['display_report'] ) {
+		# produce an error if the field is required but wasn't posted
+		if ( !gpc_isset_custom_field( $t_id, $t_def['type'] ) &&
+			( $t_def['require_report'] ||
+				$t_def['type'] == CUSTOM_FIELD_TYPE_ENUM ||
+				$t_def['type'] == CUSTOM_FIELD_TYPE_LIST ||
+				$t_def['type'] == CUSTOM_FIELD_TYPE_MULTILIST ||
+				$t_def['type'] == CUSTOM_FIELD_TYPE_RADIO ) ) {
+			error_parameters( lang_get_defaulted( custom_field_get_field( $t_id, 'name' ) ) );
+			trigger_error( ERROR_EMPTY_FIELD, ERROR );
+		}
+		if ( !custom_field_validate( $t_id, gpc_get_custom_field( "custom_field_$t_id", $t_def['type'], NULL ) ) ) {
+			error_parameters( lang_get_defaulted( custom_field_get_field( $t_id, 'name' ) ) );
+			trigger_error( ERROR_CUSTOM_FIELD_INVALID_VALUE, ERROR );
+		}
 	}
 }
 
@@ -187,7 +189,7 @@ foreach( $t_related_custom_field_ids as $t_id ) {
 	}
 
 	$t_def = custom_field_get_definition( $t_id );
-	if( !custom_field_set_value( $t_id, $t_bug_id, gpc_get_custom_field( "custom_field_$t_id", $t_def['type'], '' ), false ) ) {
+	if( $t_def['display_report'] && !custom_field_set_value( $t_id, $t_bug_id, gpc_get_custom_field( "custom_field_$t_id", $t_def['type'], '' ), false ) ) {
 		error_parameters( lang_get_defaulted( custom_field_get_field( $t_id, 'name' ) ) );
 		trigger_error( ERROR_CUSTOM_FIELD_INVALID_VALUE, ERROR );
 	}
diff --git a/bug_update.php b/bug_update.php
index eaa4669..96defaa 100644
--- a/bug_update.php
+++ b/bug_update.php
@@ -262,11 +262,11 @@ foreach ( $t_related_custom_field_ids as $t_cf_id ) {
 	$t_new_custom_field_value = gpc_get_custom_field( "custom_field_$t_cf_id", $t_cf_def['type'], null );
 	$t_old_custom_field_value = custom_field_get_value( $t_cf_id, $f_bug_id );
 
-	# Validate the value of the field against current validation rules.
+	# Validate the value of the field against current validation rules.(only if it's displayed on update)
 	# This may cause an error if validation rules have recently been
 	# modified such that old values that were once OK are now considered
 	# invalid.
-	if ( !custom_field_validate( $t_cf_id, $t_new_custom_field_value ) ) {
+	if ( $t_cf_def['display_update'] && !custom_field_validate( $t_cf_id, $t_new_custom_field_value ) ) {
 		error_parameters( lang_get_defaulted( custom_field_get_field( $t_cf_id, 'name' ) ) );
 		trigger_error( ERROR_CUSTOM_FIELD_INVALID_VALUE, ERROR );
 	}
@@ -350,7 +350,11 @@ $t_updated_bug->update( $t_text_field_update_required, true );
 
 # Update custom field values.
 foreach ( $t_custom_fields_to_set as $t_custom_field_to_set ) {
-	custom_field_set_value( $t_custom_field_to_set['id'], $f_bug_id, $t_custom_field_to_set['value'] );
+	# only set the value if it's available to the user.
+	$t_cf_def = custom_field_get_definition( $t_custom_field_to_set['id'] );
+	if( $t_cf_def['display_update'] ) {
+		custom_field_set_value( $t_custom_field_to_set['id'], $f_bug_id, $t_custom_field_to_set['value'] );
+	}
 }
 
 # Add a bug note if there is one.

Re: Applying custom fields to existing issues

Posted: 29 Oct 2010, 14:44
by atrol

Re: Applying custom fields to existing issues

Posted: 29 Oct 2010, 21:03
by istvanb
Thanks both of you for the reply. As far as I understand the radio, listbox and enumerated will cause me a problem if I do not apply the patch. What about the checkbox? Is that the same?

thx,
i-

Re: Applying custom fields to existing issues

Posted: 01 Nov 2010, 21:50
by atrol
8O seems that checkbox functionality is complete broken.
I will check this the next days with a complete new installation.

Re: Applying custom fields to existing issues

Posted: 01 Nov 2010, 22:39
by istvanb
I was able to apply a custom checkbox, however it behaved funky at my side. I assumed that if I create a checkbox then I can assign a value for FALSE and a value for TRUE and also one of them can be the default.

If I tried this then I actually got 2 checkboxes, which is not exactly as I thought it works.

Can you just send your experiences as well to see whats going on?

Re: Applying custom fields to existing issues

Posted: 02 Nov 2010, 20:32
by atrol
Strange ...., this works as designed but not as documented.
Behaviour of checkboxes as example:
Custom filed named "Colors", Values: Red|Green|Blue|Yellow
Default value: Green|Blue
--> 4 check boxes with 2 checked on (Green and Blue)
It makes not much sense to use this for somethink like On/Off because there is no string represenation for Off (so you cant't see any value when viewing the issue)
So you have to use type "Radio" for 1 selected out of 2

Re: Applying custom fields to existing issues

Posted: 03 Nov 2010, 12:47
by istvanb
From my aspect assigning a text representation to the OFF makes sense as well, however I am not sure about the coding concept behind.