|Anonymous | Login | Signup for a new account||2014-09-17 07:30 EDT|
|My View | View Issues | Change Log | Roadmap | Wiki | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0013443||mantisbt||api soap||public||2011-10-27 02:52||2014-04-23 10:55|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Description||The 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.
|Tags||No tags attached.|
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.
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.
edited on: 2011-11-07 03:48
Sounds good. I would make this actually something like
to remove any possible ambiguity.
|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.|
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.
|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.0933 seconds.|
memory usage: 3,043 KB