View Issue Details Jump to Notes ] Wiki ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013443mantisbtapi soappublic2011-10-27 02:522014-04-23 10:55
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
PlatformOSOS Version
Product Version1.2.8 
Target VersionFixed in Version 
Summary0013443: mc_issue_get_access
DescriptionThe current SOAP API has validation to make sure users can only do actions that they are authorized to do and can only view data that they are authorized to view. However, there is no way for a client tool to get the same access rules to be able to avoid the user doing an action that ends up being rejected by the service.

mc_issue_get_access( $p_username, $p_password, $p_issue_id )

This will return a collection of strings for the actions the user is allowed to take on the specified issue.

The advantage of this approach is that it provides a non-chatty approach that provides the minimal actionable data to the client.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
User avatar (0030082)
vboctor (administrator)
2011-10-27 03:10

Reminder sent to: rombert

@rombert, what are your thoughts on this approach?

I think it would be good idea if we define some web service methods to cover missing features. This way, we can implement these when we get a chance or contributors that have a good starting point.
User avatar (0030182)
vboctor (administrator)
2011-11-06 13:35

I'm thinking we should have the strings look as follows:


The advantage here is that we know if an access is denied vs not exposed by the soap API.
User avatar (0030184)
rombert (developer)
2011-11-07 03:47
edited on: 2011-11-07 03:48

Sounds good. I would make this actually something like


to remove any possible ambiguity.

User avatar (0032054)
vboctor (administrator)
2012-06-09 23:06

When we think about this, it makes sense to consider doing this on a project or multi-project level. This means that we will require different access entries for private vs. public issues within the project.
User avatar (0040136)
rombert (developer)
2014-04-23 10:55

As I previously said, the approach overall looks good to me. I'm wondering if it makes sense to add information on allowed field updates, or even on allowed field values?

Use cases would be:

- user is allowed to edit description but not priority/target version
- user is allowed to set an issue as assigned, but not as closed.

If you think it's not worthing doing now, we should still add them to the schema, so that SOAP changes down the road don't break existing clients.

- Issue History
Date Modified Username Field Change
2011-10-27 02:52 vboctor New Issue
2011-10-27 03:10 vboctor Note Added: 0030082
2011-11-06 13:35 vboctor Note Added: 0030182
2011-11-07 03:47 rombert Note Added: 0030184
2011-11-07 03:48 rombert Note Edited: 0030184 View Revisions
2012-03-06 06:55 rombert Target Version => 1.3.x
2012-06-09 23:06 vboctor Note Added: 0032054
2012-06-22 06:35 RobertPattinson Note Added: 0032148
2012-06-22 06:52 rombert Note Deleted: 0032148
2014-01-21 18:46 atrol Target Version 1.3.x =>
2014-04-23 10:55 rombert Note Added: 0040136

MantisBT 1.2.17 [^]
Copyright © 2000 - 2014 MantisBT Team
Time: 0.0869 seconds.
memory usage: 3,035 KB
Powered by Mantis Bugtracker