Applying custom fields to existing issues

Get help from other users here.

Moderators: Developer, Contributor

Post Reply
istvanb
Posts: 226
Joined: Aug 22, 2010 4:00 pm

Applying custom fields to existing issues

Post by istvanb » Oct 29, 2010 6:49 am

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?

istvanb
Posts: 226
Joined: Aug 22, 2010 4:00 pm

Re: Applying custom fields to existing issues

Post by istvanb » Oct 29, 2010 7:51 am

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.

istvanb
Posts: 226
Joined: Aug 22, 2010 4:00 pm

Re: Applying custom fields to existing issues

Post by istvanb » Oct 29, 2010 8:25 am

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?

daryn
Posts: 1
Joined: Oct 29, 2010 9:17 am

Re: Applying custom fields to existing issues

Post by daryn » Oct 29, 2010 9:35 am

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.

atrol
Site Admin
Posts: 7691
Joined: Mar 26, 2008 4:37 pm
Location: Germany

Re: Applying custom fields to existing issues

Post by atrol » Oct 29, 2010 9:44 am

Please use Search before posting and read the Manual

istvanb
Posts: 226
Joined: Aug 22, 2010 4:00 pm

Re: Applying custom fields to existing issues

Post by istvanb » Oct 29, 2010 4:03 pm

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-

atrol
Site Admin
Posts: 7691
Joined: Mar 26, 2008 4:37 pm
Location: Germany

Re: Applying custom fields to existing issues

Post by atrol » Nov 01, 2010 4:50 pm

8O seems that checkbox functionality is complete broken.
I will check this the next days with a complete new installation.
Please use Search before posting and read the Manual

istvanb
Posts: 226
Joined: Aug 22, 2010 4:00 pm

Re: Applying custom fields to existing issues

Post by istvanb » Nov 01, 2010 5:39 pm

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?

atrol
Site Admin
Posts: 7691
Joined: Mar 26, 2008 4:37 pm
Location: Germany

Re: Applying custom fields to existing issues

Post by atrol » Nov 02, 2010 3:32 pm

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
Please use Search before posting and read the Manual

istvanb
Posts: 226
Joined: Aug 22, 2010 4:00 pm

Re: Applying custom fields to existing issues

Post by istvanb » Nov 03, 2010 7:47 am

From my aspect assigning a text representation to the OFF makes sense as well, however I am not sure about the coding concept behind.

Post Reply