2014-11-23 17:07 EST

View Issue Details Jump to Notes ] Wiki ]
IDProjectCategoryView StatusLast Update
0013443mantisbtapi soappublic2014-10-24 16:52
Reportervboctor 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusnewResolutionopen 
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.
    update_issue,
    delete_issue,
    move_issue,
    monitor_issue,
    clone_issue,
    update_notes,
    update_own_notes,
    add_attachment,
    delete_attachment,
    add_tag,
    delete_tag,
    assign_issue,
    update_status,
    update_sticky,
    add_note,
    delete_note,
    add_relationship,
    delete_relationship,

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
+ Relationships

-  Notes
User avatar

~0030082

vboctor (administrator)

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)

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

add_tag/allow
delete_tag/deny

The advantage here is that we know if an access is denied vs not exposed by the soap API.
User avatar

~0030184

rombert (developer)

Last edited: 2011-11-07 03:48

View 2 revisions

Sounds good. I would make this actually something like

<actions>
 <action>
   <name>add_note</name>
   <permission>allow</permission>
  </action>
</actions>

to remove any possible ambiguity.

User avatar

~0032054

vboctor (administrator)

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)

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.
User avatar

~0041630

vboctor (administrator)

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).
User avatar

~0041636

rombert (developer)

> 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

<field>
  <name>status</name>
  <values>
    <value>resolved</value>
    <value>closed</value>
  </values>
</field>

for fields which may not be changed

<field>
  <name>target_version</name>
  <values/>
</field>

Did I understand the data structure right? (Not necessarily the final representation)
User avatar

~0041637

rombert (developer)

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?
User avatar

~0041638

vboctor (administrator)

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.
User avatar

~0041644

rombert (developer)

OK, sounds like a good initial plan
+  Notes

- 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
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
+ Issue History