Redmine

James R wrote:

Currently, Redmine uses Assignee for both Access Control and Issue Responsibility.

What do you exactly mean with "issue responsibility" in the context of Redmine usage?

I'm wondering whether there is a plugin that, or pointers on how to, separate these two functions.

From what I understand from your question I'd say that it basically comes down to making sure that you haven't configured workflow transitions specific for authors or assignees.

The reason is that once Assignee is used for Access Control (allow a Role to access an issue), it effectively cannot be used for Issue Responsibility as that responsibility changes over the bug lifetime.

Can you explain your use case here?

Edit by MTE: implementation details can be found in r4895 for #2732.

What do you exactly mean with "issue responsibility" in the context of Redmine usage?

Can you explain your use case here?

"Issue responsibility" refers to who (user or group) is currently responsible for the next action of the group. That is, who holds the token (in a ring passing) or baton (in a relay race).

For example, user internalA opens an issue and assigns it to user externalB to investigate. externalB is now responsible for the issue. externalB updates the issue, and re-assigns it to internalA. internalA is now responsible for the issue.

Now, consider that there are multiple externalX groups in a single project, and they should not see each other issues. The Redmine solution we have implemented is to create an external role with Item visibility = Items created by or assigned to user, and give these externalX groups that role.

This works well for Item visibility (Access Permissions), but now we have lost the ability to easily identify who is responsible for an issue (holds the baton) because changing the Assignee will cause externalA to no longer see the issue.

So we created a custom user field called Responsible. However, we can no longer use the built-in reports/charts/views that work on Assignee, while at the same time having a non-intuitive Assignee field used for Visibility. (I know we can rename it, but ...)

From what I understand from your question I'd say that it basically comes down to making sure that you haven't configured workflow transitions specific for authors or assignees.

Correct, we haven't used author or assignee transitions. And this wouldn't address the concern which is more about having distinct and independent methods for issue visibility/access control and issue responsibility/current ownership.

Hope this helps to understand the issue.