View Issue Details

IDProjectCategoryView StatusLast Update
0013443mantisbtapi soappublic2014-11-26 16:13
ReportervboctorAssigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version1.2.8 
Target VersionFixed in Version 
Summary0013443: mc_issue_get_access

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.

TagsNo tags attached.


related to 0016098 confirmed MantisTouch A developer cannot edit a solved bug in MantisTouch 




2011-10-27 03:10

manager   ~0030082

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.



2011-11-06 13:35

manager   ~0030182

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.



2011-11-07 03:47

developer   ~0030184

Last edited: 2011-11-07 03:48

View 2 revisions

Sounds good. I would make this actually something like


to remove any possible ambiguity.



2012-06-09 23:06

manager   ~0032054

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.



2014-04-23 10:55

developer   ~0040136

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.



2014-10-22 03:55

manager   ~0041630

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



2014-10-23 17:02

developer   ~0041636

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)



2014-10-23 17:05

developer   ~0041637

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?



2014-10-24 01:18

manager   ~0041638

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.



2014-10-24 16:52

developer   ~0041644

OK, sounds like a good initial plan

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