planser, I've raised this during the development of the category id work. The dev that developed the categories feature is not familiar with the SOAP stuff. Are you able to handle this issue?

The issue here is how to design/implement this without breaking backward compatibility. So far we haven't defined a detailed criteria for our backward compatibility strategy. But my concern is that if we break it, then applications that are developed and shipped by users will break when the communicate with Mantis after an upgrade.

At the moment we have a category field of type string in IssueData. We may want to consider adding a category2 field of type objectRef. When submitting an issue the web service checks category2 then category. When returning issue data the web service will populate both.

What do you think? I didn't check the code now, so I may be missing something.

Well, at least for Java respectively Axis an additional field means regenerating the client stubs but it doesn't really break backward compatibility for existing apps.

Honestly I don't like the additional field and I would like to see the API updated. The SOAP API was never part of an official release of Mantis. And MantisConnect itself officially only had alpha-releases.

But I understand that there are apps based on MantisConnect for which backward compatibility is important.

Categories are unique within projects. Maybe we could map the string to the appropriate id on the server...

I totally missed the target version, so please forget my comment about the SOAP API never being part of an official release. It is (as it's part of 1.1.0).

So backward compatibility is important.

OK, now it's time to make a decision.

Honestly I don't like the idea to carry the category the category twice.

Instead of adding a category2 field of type objectRef we could consider adding a field of type integer - the id of the category.

When submitting an issue the web service checks the id of the category. When returning issue data the web service will populate both.

in 0009320 i added a note with a patch for a refactoring / incompatability issue:

api/soap/mc_issue_api.php not recactored in line with interface change of bugnote_get_all_visible_bugnotes(...)

Index: api/soap/mc_issue_api.php

--- api/soap/mc_issue_api.php (revision 10)
+++ api/soap/mc_issue_api.php (revision 11)
@@ -259,7 +259,7 @@
$t_user_bugnote_order = 'ASC'; // always get the notes in ascending order for consistency to the calling application.

     $t_result = array();

• foreach( bugnote_get_all_visible_bugnotes( $p_issue_id, $t_user_access_level, $t_user_bugnote_order, 0 ) as $t_value ) {
• foreach( bugnote_get_all_visible_bugnotes( $p_issue_id, $t_user_bugnote_order, 0 ) as $t_value ) {
  $t_bugnote = array();
  $t_bugnote['id'] = $t_value->id;
  $t_bugnote['reporter'] = mci_account_get_array_by_id( $t_value->reporter_id );

Does someone of the Mantis team maintain the Mantisconnect code? There are other issues when creating bugs over soap... Maybe I could give a helping hand on this but it will need some time...

Regarding backward compatibility... I changed a few lines in bug_api.php so there was no need to update the Mantisconnect files (default for missing due date or fetching category_id when only category is given). This would be another way to make sure Mantisconnect works with Mantis 1.1.X / 1.2.X but thats a quickhack, I know...

@dominik, what did you change? could you attach or paste details on the changes? or put details on the wiki page?

bug_api.php - bug_create():

• due date: make sure we always have a due date especially when no one was given
• translate category to category_id (I didn't code the real translation yet, because for the moment I only use one Mantis (which has 1.2.0a1)...

481c481,487
< $c_sticky = 0;

  $c_sticky               = 0;
  $c_due_date             = 0;

  # quickhack (2008-07-02 Sleeper)
  if(is_numeric($p_bug_data->category)) {
      $c_category_id = db_prepare_int( $p_bug_data->category );
  }

511a518,521
if(substr($c_due_date, 0, 4) < 1970) {

set due date to default

      $c_due_date = '1970-01-01 00:00:01';
  }

964a975,978
}
if(substr($c_due_date, 0, 4) < 1970) {

set due date to default

      $c_due_date = '1970-01-01 00:00:01';

mc_api.php - mci_category_get_all_rows():

• change name check to id check

273c273
< $query = "SELECT c.name as category FROM $t_category_table AS c

  $query = "SELECT c.id as category FROM $t_category_table AS c

277c277
< ORDER BY c.name ";

          ORDER BY c.id ";

That should do the trick...

dominik, I think I'll give it a try. But I won't translate the category to category_id in bug_api.php but within MantisConnect.

If it works we do not need to add a category2 field of type ObjectRef. Plus we don't need another webservice call mc_project_get_categories2() which returns an array of ObjectRefs.

The category is still of type string. When adding/updating an issue MantisConnect tries to find a category which is part of the project the issue is added to / updated (api/soap/mc_api.php#translate_category_name_to_id()).