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.

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.

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

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

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