|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0013443||mantisbt||api soap||public||2011-10-27 02:52||2014-11-26 16:13|
|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.
Last edited: 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.
One way to achieve the requirements here is to return back a property bag with string key and value. Entries will include:
- What operations are supported? issue_update=true, issue_delete=false
- What possible values are allowed for specific fields? e.g. Status=Resolved, Closed (based on workflow)
For the schema the property bag is the most flexible, but not fantastic for auto-generated code. However, I think having a schema that we keep extending for this as more controls are added (or implemented in this API) can be an overkill.
If we go to a structure like the one you suggested as strongly typed, then we will have three fields per entry: name, permission, possible_values. With possible values supporting null (for any).
> not fantastic for auto-generated code
Not sure what you mean by that
> we will have three fields per entry: name, permission, possible_values
so possible values ( if we are for argument's sake to make this as typed as possible ) could be something like
for fields which may not be changed
Did I understand the data structure right? (Not necessarily the final representation)
Something else crossed my mind - could we implement this internally for the core of Mantis and then use the same codebase for the SOAP API? This would go a long way towards insuring consistency and we could start small, e.g. with add_note.
Also, I just realized that we need to indicate permissions to edit/delete attached objects like notes, or even attributes of notes ( time tracking data, reminder ). How would you see that expressed?
At one point I was suggesting have access_issue_assign( $p_issue_id ), access_issue_delete( $p_issue_Id ), access_issue_add_note( $p_issue_id ), etc. Such API knows what config value to get the threshold from and does the appropriate logic. Rather than having everywhere across the code base know all these details and call into feature neutral API.
Such API will also easily abstract logic around "edit my own notes" vs. "edit all notes" rather than calling code having to understand such complexity.
For attached related objects, they will just end up being just another access priviidege on the issue - as per my list in the issue description -- add_note, add_relationship, etc.
When we address this, I would rather start with the SOAP experience, and then we can address the internal cleanup of trying to abstract this code into APIs rather than all the pages exposing the functionality.
|OK, sounds like a good initial plan|
|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.0-beta.1|
|2012-06-09 23:06||vboctor||Note Added: 0032054|
|2014-01-21 18:46||atrol||Target Version||1.3.0-beta.1 =>|
|2014-04-23 10:55||rombert||Note Added: 0040136|
|2014-10-22 03:55||vboctor||Note Added: 0041630|
|2014-10-23 17:02||rombert||Note Added: 0041636|
|2014-10-23 17:05||rombert||Note Added: 0041637|
|2014-10-24 01:18||vboctor||Note Added: 0041638|
|2014-10-24 16:52||rombert||Note Added: 0041644|
|2014-11-26 16:13||vboctor||Relationship added||related to 0016098|