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.

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 )

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

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

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

@vboctor: I've checked out mantisbt up to

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

Fix #8284: 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.

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

Yes, please file a separate bug for it.

And thus issue 0009805 is born.

Resolved based on @rombert comment in issue 0008284