View Issue Details

IDProjectCategoryView StatusLast Update
0009337mantisbtapi soappublic2009-06-26 12:03
Reporterrombert Assigned Tovboctor  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.1.2 
Fixed in Version1.2.0a3 
Summary0009337: [patch] Target version is not erased anymore when using the SOAP API
Description

I have created a simple patch which allows issues to be updated using the SOAP API without erasing the target version.

This also allows the web interface to function properly, so it's a pure bugfix.

Patch created against 5338 (1.1.2)

Tagspatch
Attached Files
preserve-target-version-soap.patch (1,654 bytes)   
Index: api/soap/mc_issue_api.php
===================================================================
--- api/soap/mc_issue_api.php	(revision 5388)
+++ api/soap/mc_issue_api.php	(working copy)
@@ -685,7 +685,7 @@
         $t_bug_data->additional_information = isset( $v_additional_information ) ? $v_additional_information : '';
 
         # submit the issue
-        $t_is_success = bug_update($p_issue_id,$t_bug_data,true,false );
+        $t_is_success = bug_update($p_issue_id,$t_bug_data,true,false, false );
 
         mci_issue_set_custom_fields( $p_issue_id, $v_custom_fields );
 
Index: core/bug_api.php
===================================================================
--- core/bug_api.php	(revision 5388)
+++ core/bug_api.php	(working copy)
@@ -777,7 +777,7 @@
 	# --------------------
 	# Update a bug from the given data structure
 	#  If the third parameter is true, also update the longer strings table
-	function bug_update( $p_bug_id, $p_bug_data, $p_update_extended = false, $p_bypass_mail = false ) {
+	function bug_update( $p_bug_id, $p_bug_data, $p_update_extended = false, $p_bypass_mail = false, $p_update_target_version = true ) {
 		$c_bug_id		= db_prepare_int( $p_bug_id );
 		$c_bug_data		= bug_prepare_db( $p_bug_data );
 
@@ -829,7 +829,7 @@
 					fixed_in_version='$c_bug_data->fixed_in_version',";
 
 		$t_roadmap_updated = false;
-		if ( access_has_project_level( config_get( 'roadmap_update_threshold' ) ) ) {
+		if ( $p_update_target_version && access_has_project_level( config_get( 'roadmap_update_threshold' ) ) ) {
 			$query .= "
 					target_version='$c_bug_data->target_version',";
 			$t_roadmap_updated = true;

Relationships

related to 0009245 closedvboctor target_version not passed through via SOAP 

Activities

giallu

giallu

2008-07-04 05:10

reporter   ~0018301

Last edited: 2008-07-04 05:12

I surely agree that's an ugly bug we should get rid of.
That said, the patch does not look good to me: for a start, it changes the API without a strong reason.

Then, if the target version is lost is because the bug_update function is receiving an empty field from the soap api. It seems to me that a better fix should be this one:
<pre>
Index: api/soap/mc_issue_api.php

--- api/soap/mc_issue_api.php (revision 5388)
+++ api/soap/mc_issue_api.php (working copy)
@@ -668,6 +668,7 @@
$t_bug_data->os_build = isset( $v_os_build ) ? $v_os_build : '';
$t_bug_data->platform = isset( $v_platform ) ? $v_platform : '';
$t_bug_data->version = isset( $v_version ) ? $v_version : '';

  • $t_bug_data->target_version = isset( $v_target_version ) ? $v_target_version : '';
    $t_bug_data->fixed_in_version = isset( $v_fixed_in_version ) ? $v_fixed_in_version : '';
    $t_bug_data->build = isset( $v_build ) ? $v_build : '';
    $t_bug_data->view_state = $t_view_state_id;
    </pre>

can you please double check if it works? if it works I will happily apply the change.

rombert

rombert

2008-07-04 13:50

reporter   ~0018307

Last edited: 2008-07-04 13:53

I completely agree with your assessment of the patch. It's just a hack.

On the other hand, with your patch the target_version field is still blanked out.

As far as I know, the target_version is not yet added to the SOAP api ( see 0009245 for a bug report + patch which tries to add it to the SOAP api ) and this is why I have resorted to the hackish solution, since I'm not up to adding the field to the SOAP api ( but perhaps jeremib is )

giallu

giallu

2008-07-07 06:02

reporter   ~0018322

Thanks for testing my patch. It seems the problem is much more involved than I expected as the SOAP api does not seem to be robust enough to cope with the missing parameter, or maybe it's just me not understanding it properly...

rombert

rombert

2008-07-07 12:25

reporter   ~0018328

I would really like to get the target_version sorted out, but I'm more or less at a loss when it comes to how to do do it.

Is there anyone that I could ping about how to add a field to the SOAP API ( a very bird's eye view of the process, I did my part of PHP programming until about 3 years ago )?

vboctor

vboctor

2008-11-12 03:04

manager   ~0019846

@rombert, can you please test the fix for 0009245 and see if it fixes the problem you are having.

rombert

rombert

2008-11-12 05:34

reporter   ~0019848

Last edited: 2008-11-12 05:35

@vboctor: I've checked out mantisbt up to

commit d7f2a839e0945fd34f8353423c6889287ffe46dc
Author: Victor Boctor
Date: Tue Nov 11 23:55:19 2008 -0800

Fix 0008284: SOAP API doesn't support target_version.

But I can't retrieve any issue headers using a filter ( which is the workflow I'm using )

When requesting:

<pre>
<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; xmlns:xsd="http://www.w3.org/2001/XMLSchema&quot; xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/&quot; xmlns:man="http://futureware.biz/mantisconnect&quot;>
<soapenv:Header/>
<soapenv:Body>
<man:mc_filter_get_issue_headers soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/&quot;>
<username xsi:type="xsd:string">administrator</username>
<password xsi:type="xsd:string">root</password>
<project_id xsi:type="xsd:integer">1</project_id>
<filter_id xsi:type="xsd:integer">1</filter_id>
<page_number xsi:type="xsd:integer">1</page_number>
<per_page xsi:type="xsd:integer">50</per_page>
</man:mc_filter_get_issue_headers>
</soapenv:Body>
</soapenv:Envelope>
</pre>

I get back

<pre>
<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/&quot; xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/&quot; xmlns:xsd="http://www.w3.org/2001/XMLSchema&quot; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/&quot;>
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode xsi:type="xsd:string">Server</faultcode>
<faultactor xsi:type="xsd:string"/>
<faultstring xsi:type="xsd:string">Invalid Filter</faultstring>
<detail xsi:type="xsd:string"/>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
</pre>

So I really can't test this ATM.

rombert

rombert

2008-11-12 05:37

reporter   ~0019849

Same steps work fine with 1.1.x . Should I file a separate bug report for this?

vboctor

vboctor

2008-11-12 12:33

manager   ~0019853

Yes, please file a separate bug for it.

rombert

rombert

2008-11-12 14:47

reporter   ~0019856

And thus issue 0009805 is born.

vboctor

vboctor

2009-05-22 04:08

manager   ~0021876

Resolved based on @rombert comment in issue 0008284