View Issue Details

IDProjectCategoryView StatusLast Update
0009337mantisbtapi soappublic2009-06-26 12:03
Reporterrombert 
Assigned Tovboctor 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.1.2 
Target VersionFixed 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

Relationships

related to 0009245 closedvboctor target_version not passed through via SOAP 

Activities

2008-07-03 17:36

 

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;
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:

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;

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

rombert

rombert

2008-07-04 13:50

developer   ~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

developer   ~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

developer   ~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 <a href="/bugs/view.php?id=8284" title="[closed] SOAP API doesn't support target_version" class="resolved">0008284</a>: 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:

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:man="http://futureware.biz/mantisconnect">
   <soapenv:Header/>
   <soapenv:Body>
      <man:mc_filter_get_issue_headers soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
         <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>

I get back

<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
   <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>

So I really can't test this ATM.

rombert

rombert

2008-11-12 05:37

developer   ~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

developer   ~0019856

And thus issue 0009805 is born.

vboctor

vboctor

2009-05-22 04:08

manager   ~0021876

Resolved based on @rombert comment in issue 0008284

Issue History

Date Modified Username Field Change
2008-07-03 17:36 rombert New Issue
2008-07-03 17:36 rombert File Added: preserve-target-version-soap.patch
2008-07-04 05:10 giallu Note Added: 0018301
2008-07-04 05:12 giallu Note Edited: 0018301
2008-07-04 13:50 rombert Note Added: 0018307
2008-07-04 13:53 rombert Note Edited: 0018307
2008-07-07 06:02 giallu Note Added: 0018322
2008-07-07 12:25 rombert Note Added: 0018328
2008-07-15 15:40 grangeway Status new => assigned
2008-07-15 15:40 grangeway Assigned To => grangeway
2008-11-12 03:02 vboctor Tag Attached: patch
2008-11-12 03:03 vboctor Relationship added related to 0009245
2008-11-12 03:04 vboctor Note Added: 0019846
2008-11-12 03:04 vboctor Status assigned => feedback
2008-11-12 05:34 rombert Note Added: 0019848
2008-11-12 05:35 rombert Note Edited: 0019848
2008-11-12 05:35 rombert Note Edited: 0019848
2008-11-12 05:37 rombert Note Added: 0019849
2008-11-12 12:33 vboctor Note Added: 0019853
2008-11-12 14:47 rombert Note Added: 0019856
2009-05-22 04:06 vboctor Status feedback => assigned
2009-05-22 04:06 vboctor Assigned To grangeway => vboctor
2009-05-22 04:08 vboctor Note Added: 0021876
2009-05-22 04:08 vboctor Status assigned => resolved
2009-05-22 04:08 vboctor Fixed in Version => 1.2.0a3
2009-05-22 04:08 vboctor Resolution open => fixed
2009-06-26 12:03 vboctor Status resolved => closed