We do not assign the TeamView claim to our customers as we do not want customers from CompanyA seeing the Teams we have created from CompanyB.
However, we do assign the ProcessView claim so that the deployment process\logic is visible and not a blackbox.
When they click on the Manual Intervention Step, the Responsible Teams is empty.
I believe this behaviour isn’t quite right. I believe they should be able to see the assigned Team(s), but not be able to see the complete list of Teams.
Proposed behaviour…
As the Process view is read-only, you could argue that the dropdown should not be enabled, which would then allow the selected Team(s) to be visible without violating the TeamView claim and showing all available Teams.
Additional to this, it may also make sense to allow Teams to be associated with a Tenant(s). This would then allow the TeamView claim to be assigned without opening a gap in security.
Related but separate issue…
I have also attached a screenshot of another error generated by not having the TeamView claim. Octopus displays an “An unexpected error” message at the top of the project page which is quite ugly for our customers and appears like a bug (unhandled exception).
Thanks for getting in touch and the detailed breakdown. We’re moving our permission system forward to be more consistent obeying common rules. This is part of the upcoming Spaces feature. It’s looking like Spaces will give you the desired isolation that the permissions alone cannot handle well enough.
In the Spaces feature you will be able to have top level teams that everyone can see. Each Space will be able to define teams that exist in isolation there.
To reproduce the exact thing you were showing, I had to add an “email step” does your deployment process also contain that? When I first re-created what you described with just a manual intervention step the error showed in a different spot, and not at the deployment process summary, but only when looking at that steps details:
Back to the permissions, a major one of the consistencies we’re applying is to only load a resource (e.g. Team) if the user does hold that permission, otherwise we leave the system open to these gaps.
I agree showing that error isn’t ideal, but the system did require that the user holds the TeamView permission to load the linked data in the deployment process.
Those “errors” are there deliberately, we use them to guide users to configure permissions they may not know they are missing. Your case is logical, but is more rare, and will be supported differently via Spaces.
If you could make a “Space” per customer (or group of customers) does that sound like it will be the level of isolation you need?
