Hi all,
I tried to include every relevant information. If I missed anything, I'll happily provide it!
We've encountered an issue with the restriction of issues in a team-managed software project.
We have a few custom issue types, but this affects all issue types - custom or standard ones.
We have created a custom role ("Fachbereich") for a group of users which shouldn't see specific issue types (bugs). It should be possible to de-restrict non-sensitive bugs to this group or if their collaboration is needed.
To achieve this, we've restricted the visibility of this specific and other issue types to the other roles ("Fachbereich" excluded) by default:
Afaik, the possibility to restrict a issue or remove an existing restriction for an issue is linked to the permission "restrict any issue" which is by default granted to the roles "Member" and "Administrator":
Users with the role "Member" should therefore be able to restrict and change the restriction of a issue (because some issues contain sensitive information, some issues don't) when creating/viewing one. This can be done via the lock-symbol while viewing a issue.
However, they (Members, default role) only get the following error when clicking the lock-symbol when viewing an issue: Translation: "We couldn’t find your issue type’s restrictions. Refresh the page and try again." It doesn't matter if it's an old issue created before the default restriction was implemented (so there's no active restriction for the issue), new issues with the default restriction or an issue of a type for which no default restriction is defined.
However, Administrators (default role) are able to change the restriction of old existing (created before the default restriction was implemented) and existing (created after the default restriction was implemented) issues without a problem.
I've made a copy of the default Member role and granted the permission to administer the specific project and users with this role are also able to restrict issues without a problem.
However, the permission to administer the project should only be needed for changing the default restriction, at least that's what I understood from the description:
It would not make much sense to mention the role Member in the article linked/posted above, if they're not able to use this function anyway:
And one of our Members involved in implementing/deciding the implementation of the default restriction is sure that he was able to at least see the existing restrictions and almost sure that he was able to change them as well in the past.
Has anyone encountered the same issue before?
Is this a bug or a misunderstanding on our side?
Does anyone have a clue why this could be?
Thank you very much in advance!
Johann
