You do not have permission to perform this action. Please contact your Octopus administrator. Missing permission: TaskCreate
This action requires permission to explicitly create (run) server tasks. At least one of your teams has this permission in a limited scope, but this doesn’t cover the project or environment in question. Teams that have enough permission include: TeamCity Agents group and Octopus Administrators.
This user is in a team that contains the above environment, and has the following roles: Project deployer, Project lead, Environment manager, Package publisher, Package Viewer.
The Test Permissions page for that user shows that they do have the TaskCreate permission for that environment.
Any idea what else I need to do to give the user permission to run a health check?
Thanks for reaching out. The TaskCreate permission has to be provided by a team that is not scoped to a specific project (meaning the scope is set to All Projects). Since Environments can be shared across projects, and the Health Check can momentarily interrupt the connection with the Tentacles, we need to make sure that the person running the Health Check is someone that is aware of all the projects that might be using this tentacle. Hence this restriction.
Hi Dalmiro,
Thanks for your reply.
How about making it so that, if a user has the correct permissions on ALL of the projects that the environment is used by, they can perform a health check on that environment?
Thanks,
Stephen
Let’s say you have 3 projects: Project1, Project2, Project3. And you have 2 environments: Stage, Production. Only Project1 and Project2 are using the Production environment
If you want a user to be able to run a health check on Production, he’s gonna need to be on a team scoped to “All Projects”. If he’s on 2 teams, where each grant him permissions over Project1 and Project2 (respectively), the user still wont be able to run a health check even though he has access to all the projects where this environment is being used.
The reason behind this is that if another project is created afterwards (Project4), and it uses the Production environment, this user should have access to it (without having to manually grant him access).
Would you explain what you mean by “Environments can be shared across projects”? We are getting the same error (“Missing permission: TaskCreate”) but are not able, for policy reasons, to scope our Teams to “All Projects”. I’m having trouble understanding why scoping a Team to “All Projects” is a requirement for doing a health check.
Would you explain what you mean by “Environments can be shared across projects”?
Let’s say you have an environment called Production with 3 machines in it. Any project can use a lifecycle that includes this environment, thus being able to deploy to these 3 machines. This is what I mean by “it can be shared across projects”. Any project can deploy to them.
Another important concept to keep in mind is that “Health Checks” can block a machine from being deployed to it momentarily, which is a big deal for production machines. So the user triggering the “Health Check” has to be someone with access to all of the projects where the environment “Production” is being used.
So what about the case where you start with the situation you just described. Then you add a separate environment with 3 separate machines and it’s own lifecycle and projects. That separate environment could have access from a completely different team. Would it still be a requirement that a user from the first team have access to the projects from the second team? (see attached)
Let’s say this Production environment is being used by Project1 and Project2
User1 belongs to a team that grants him access to Production, Project1 and Project2(not “all projects”, but these 2 in particular). Since he has access to the 2 projects that use this environment, we can say he’s aware of when deployments take place on each project, so he should know when is the right time for a Health Check(HC), right? Let’s imagine we grant him the right to run HC at this point.
Project3 gets created, and it also uses Production in his lifecycle. User1 doesn’t have access to this new project, so he won’t know when it’ll the right time to trigger a HC without getting in the way of Project3
If User1 triggers a HC in Production at this point, he could interfere with deployments in Project3. So what should we do in this case? Should we let User1 interfere with deployments in Project3, or should we prevent him from running HC in Production altoghether just because a new Project decided to use Production? each of these approaches would surely annoy members of the other project.
To make sure that the user that can manually trigger HCs is aware of the status of all the projects using this environment, he needs to have access to “All Projects” and not just “all the project that are using this environment right now”, because of the “New environment” scenario explained above.
While I do see why this would be rather inconvenient in your case, I hope you can understand our logic behind this design choice.
