Open bethesque opened 3 years ago
To further this (using the looser definition) and working within the existing permissions model, would an administrator then also need to ensure that the contractor does not have contract_data:manage:*
or contract_data:manage:team
permission, to prevent them from publishing a new (dummy) integration for Foo -> Bob
and see the contract for Bar -> Bob
?
and see the contract for Bar -> Bob
I don't think that would be an issue.
see all the pacts and verification results where either the consumer or provider is one of your team's applications.
Neither Bar nor Bob is one of the contractor's team's applications.
Currently, every user has contract_data:read:*
, so there's no scoping used when creating a pact to see whether or not the user can read the application that the pact is for. We will have to add that logic in so a user can only create a pact for an application they're allowed to read already.
Scenario
Imagine the following integrations
Foo -> Bar Foo -> Hat Bar -> Bob Alice -> Foo
A contractor comes to work for a company to work on application Foo. The Pactflow administrator makes a new team, and assigns the contractor to the team, and adds Foo to the team. They make a new role that only has
contract_data:read:team
, and assigns the role to the contractor.If we take the strictest definition possible of
contract_data:read:team
then the contractor wouldn't even be able to see the pacts for the integrated applications. That would defeat the purpose of Pactflow, so let's assume that if you haveread:team
scope for an application, then you can also see all the pacts and verification results where either the consumer or provider is one of your team's applications.That means that our contractor would be able to see
Foo -> Bar
,Foo -> Hat
andAlice -> Foo
. They would not be able to seeBar -> Bob
.