You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
mutation updateOpenshift ($envid: Int!, $targetID: Int!) {
updateEnvironment(input:{
id: $envid,
patch: {
openshift: $targetID
}
}) {
id
name
openshift {
id
name
}
}
}
we receive the following error
Unauthorized: You don't have permission to \"update:undefined\" on \"environment\": {\"project\":
In speaking with @tobybellwood about this, he suggested that simply allowing users with the correct privileges to update the openshift field may be potentially problematic.
As a safety net, he suggests that we only allow the openshift to be updated if it is in accord with the current deploy target configuration. This would set up at least some minimal safety net in that changing the deploy target will at least be a two step process (i.e. update deploy target config, then update the field on the environment itself).
To Reproduce
As a maintainer of the project, run the graphql given above with the appropriate values set
get the error back from the API
Expected behavior
The openshift field value is updated.
Additional context
This is an issue that is blocking writing cluster migration scripts
The text was updated successfully, but these errors were encountered:
I'd also recommend that we add a dedicated resolver to updateEnvironmentDeployTarget that accepts the deployTarget ID. This will then log into the Audit log to make it crystal clear when this has happened.
Describe the bug
On running the following mutation
we receive the following error
Unauthorized: You don't have permission to \"update:undefined\" on \"environment\": {\"project\":
In speaking with @tobybellwood about this, he suggested that simply allowing users with the correct privileges to update the openshift field may be potentially problematic.
As a safety net, he suggests that we only allow the
openshift
to be updated if it is in accord with the current deploy target configuration. This would set up at least some minimal safety net in that changing the deploy target will at least be a two step process (i.e. update deploy target config, then update the field on the environment itself).To Reproduce
Expected behavior
The openshift field value is updated.
Additional context
This is an issue that is blocking writing cluster migration scripts
The text was updated successfully, but these errors were encountered: