Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-12300

affectsVersion field cannot be updated via SOAP or XMLRPC

    • Icon: Bug Bug
    • Resolution: Not a bug
    • Icon: Medium Medium (View bug fix roadmap)
    • None
    • 3.7.2, 3.7.3, 3.7.4
    • None

      The following PERL script works for fixVersions but NOT affectsVersions:

      		my $jiraToken	= 	XMLRPC::Lite->proxy('http://jira.atlassian.com/rpc/xmlrpc');
      		my $authToken	= 	$jiraToken->call( "jira1.login", $user, $pass )->result();
      
      		my $call 	= 	$jiraToken->call("jira1.updateIssue", $authToken, "TST-9485",
      				  		{
      				  			"fixVersions" 	=> 	[SOAP::Data->type(string => "10330")]
      				  		}				  		
      				  	);
      
      
      		
      
      		$jiraToken->call("jira1.logout", $authToken);
      

      The same code but specifying affectsVersions:

      		my $jiraToken	= 	XMLRPC::Lite->proxy('http://jira.atlassian.com/rpc/xmlrpc');
      		my $authToken	= 	$jiraToken->call( "jira1.login", $user, $pass )->result();
      
      		my $call 	= 	$jiraToken->call("jira1.updateIssue", $authToken, "TST-9485",
      				  		{
      				  			"affectsVersions" 	=> 	[SOAP::Data->type(string => "10330")]
      				  		}				  		
      				  	);
      
      
      		
      
      		$jiraToken->call("jira1.logout", $authToken);
      

      Note: The same issue occurs using the equivalent SOAP calls in PERL.

            [JRASERVER-12300] affectsVersion field cannot be updated via SOAP or XMLRPC

            Tim Burris added a comment - - edited

            I wonder if there's any way to give a field two names (from updateIssue's perspective) so you can preserve backwards compatibility but still make incoming and outgoing soap transactions match.

            Tim Burris added a comment - - edited I wonder if there's any way to give a field two names (from updateIssue's perspective) so you can preserve backwards compatibility but still make incoming and outgoing soap transactions match.

            AntonA added a comment -

            Hi James,

            Sorry for the delay in responding.

            You are right the name of fields are a bit confusing. You need to use the values that are defined as constants in:
            http://www.atlassian.com/software/jira/docs/api/latest/com/atlassian/jira/issue/IssueFieldConstants.html

            Unfortunately changing them would be hard without breaking backwards compatibility. Therefore the solution is not
            really a "work around".

            I will resolve this issue for now. Actually the best place to ask developer related questions for JIRA is the JIRA Dev forum:
            http://forums.atlassian.com/forum.jspa?forumID=100

            Thanks,
            Anton

            AntonA added a comment - Hi James, Sorry for the delay in responding. You are right the name of fields are a bit confusing. You need to use the values that are defined as constants in: http://www.atlassian.com/software/jira/docs/api/latest/com/atlassian/jira/issue/IssueFieldConstants.html Unfortunately changing them would be hard without breaking backwards compatibility. Therefore the solution is not really a "work around". I will resolve this issue for now. Actually the best place to ask developer related questions for JIRA is the JIRA Dev forum: http://forums.atlassian.com/forum.jspa?forumID=100 Thanks, Anton

            Yes - the workaround did the trick! Should status of this issue be updated to "Open" then?

            James Kleist added a comment - Yes - the workaround did the trick! Should status of this issue be updated to "Open" then?

            Taking a look at the source code found that an Orderable field will be updated if the provided RemoteFieldValue's Id matches with its Id, i.e. in UpdateFieldsHelperBeanImpl:

            final OrderableField orderableField = fieldScreenRenderLayoutItem.getOrderableField();
            if (actionParams.containsKey(orderableField.getId()))
            { // ...
            

            Therefore, to get around this, you will have to use "versions" (see IssueFieldConstants.AFFECTED_VERSIONS), e.g.

            my $updatedIssue = $soap->updateIssue($auth->result(), $issue->result()->{key}, [
            
              {"id" => SOAP::Data->type(string => "fixVersions"), 
               "values" => [SOAP::Data->type(string => "10002")]
              },
            
              {"id" => SOAP::Data->type(string => "versions"), # not "affectsVersions"
               "values" => [SOAP::Data->type(string => "10002")]
              }
            
            ]);

            Cheers,
            Yuen-Chi Lian

            Yuen-Chi Lian [Atlassian] added a comment - Taking a look at the source code found that an Orderable field will be updated if the provided RemoteFieldValue 's Id matches with its Id , i.e. in UpdateFieldsHelperBeanImpl : final OrderableField orderableField = fieldScreenRenderLayoutItem.getOrderableField(); if (actionParams.containsKey(orderableField.getId())) { // ... Therefore, to get around this, you will have to use "versions" (see IssueFieldConstants.AFFECTED_VERSIONS ), e.g. my $updatedIssue = $soap->updateIssue($auth->result(), $issue->result()->{key}, [ { "id" => SOAP::Data->type(string => "fixVersions" ), "values" => [SOAP::Data->type(string => "10002" )] }, { "id" => SOAP::Data->type(string => "versions" ), # not "affectsVersions" "values" => [SOAP::Data->type(string => "10002" )] } ]); Cheers, Yuen-Chi Lian

              Unassigned Unassigned
              4dba35587546 James Kleist
              Affected customers:
              0 This affects my team
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: