View Issue Details

IDProjectCategoryView StatusLast Update
0023806mantisbtapi soappublic2018-01-12 07:52
Reportermantisiator Assigned To 
Status newResolutionopen 
Product Version2.9.0 
Summary0023806: Developer can not close an issue unless "Assign issue" right is given when using the mc_update_issue() function

I have encountered a different behaviour when moving from 2.8.0 to 2.9.0.
More precisely:

  • I am using the mc_update_issue function() in the soap api (via Curl).
  • When executing an xml script in order to closed an issue, I have the following message in 2.9.0 which I did not have in 2.8.0:
    <faultstring>Access denied for user XXXXX. Reason: User does not have access right to assign issues.</faultstring>

Further to review , it appears that the function mc_issue_update() calls in 2.9.0:
if( !mci_has_readwrite_access( $t_user_id, $t_project_id ) ) {
return mci_fault_access_denied( $t_user_id );
while it calls in 2.8.0:
if( !mci_has_readwrite_access( $t_user_id, $t_project_id ) ) {
return mci_soap_fault_access_denied( $t_user_id );

but I could not find the associated issue in the 2.9.0 release note.

When giving the "Assign issue" right to the developper, the problem disappears, but I do not see the reason why the Assign issue should block the issue closure.

For complementary information:

  • for the project , the developer could (before adding the "assign issue") :
    update issue/handle issue/update issue status/
  • and then could only move the issue to "delivered" status which is the final status when adding the "assign issue" right to the role.

$g_status_enum_string ='15:submitted,50:assigned,35:underwork,36:underintegration,95:cancelled,

TagsNo tags attached.


related to 0023654 closedvboctor Don't validate handler when updating issues without updating handler 




2018-01-10 09:31

developer   ~0058522

Last edited: 2018-01-10 09:32

I did not investigate in details, but the change in mc_issue_api.php you mention was introduced in 2.3.0, not 2.9.0 (see MantisBT master 57104f6b) so this is likely not the root cause of your problem (unless you mixed up versions in your report).

The error message you mention is triggered by mci_issue_handler_access_check(), called by mc_issue_update() at line 1207. This bit check was added to fix 0023654 / MantisBT master 00dec0b1

@vboctor can you have a look ?

EDIT: bloody source integration links



2018-01-12 07:52

reporter   ~0058530

It is indeed not version 2.8.0 which was meant.
But the problem appears in 2.9.0
What do you think ?