2014-11-27 05:28 EST

View Issue Details Jump to Notes ] Wiki ]
IDProjectCategoryView StatusLast Update
0009337mantisbtapi soappublic2009-06-26 12:03
Reporterrombert 
Assigned Tovboctor 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
Product Version1.1.2 
Target VersionFixed in Version1.2.0a3 
Summary0009337: [patch] Target version is not erased anymore when using the SOAP API
DescriptionI 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
  • patch file icon preserve-target-version-soap.patch (1,654 bytes) 2008-07-03 17:36 - 
    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;
    
    patch file icon preserve-target-version-soap.patch (1,654 bytes) 2008-07-03 17:36 + 

- Relationships
related to 0009245closedvboctor target_version not passed through via SOAP 
+ Relationships

-  Notes
User avatar

~0018301

giallu (developer)

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.

User avatar

~0018307

rombert (developer)

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 )

User avatar

~0018322

giallu (developer)

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...
User avatar

~0018328

rombert (developer)

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 )?
User avatar

~0019846

vboctor (administrator)

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

~0019848

rombert (developer)

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:

<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.

User avatar

~0019849

rombert (developer)

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

~0019853

vboctor (administrator)

Yes, please file a separate bug for it.
User avatar

~0019856

rombert (developer)

And thus issue 0009805 is born.
User avatar

~0021876

vboctor (administrator)

Resolved based on @rombert comment in issue 0008284
+  Notes

- 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
+ Issue History