These should really be scoped. If users are inside orgs, even if they areorg-admins they should not be able to read across org boundaries.

The organization boundaries have to be kept.

Right now it's impossible to check this without extending the database that would link ProvisionerJobs to owners.

I'll do that in a separate PR.

Wouldn't regular members need this permission too? To create the jobs for their workspaces?

They would, but I'm not sure I want to polute the RBAC with assigning members access to all provisioner jobs.

We currently don't check this at all. I'll introduce another PR that separetly focuses on solving this issue.

The comment should probably mention all the ways a job could be made and what the permission check should look like. I think the following is correct:

• template_version_import jobs require eithertemplate_version:create on the org (if creating a new template) ortemplate:update andtemplate_version:create on the template (if pushing a new version)
• template_version_dry_run jobs require permissions toworkspace:create in the org as well astemplate_version:read on the specific template version
• workspace_build jobs requireworkspace:update on the specific workspace as well astemplate_version:read on the specific template version

I just don't want the comment to only say that workspace ownership needs to be checked, and for some poor soul to start working on this thinking it'll be simple when in reality it will probably be difficult.

Likely should have a ticket created to track this too. You might want to add a comment here in the code with the ticket number after you create it.

Left a simple description with link to the issue to not duplicate information.

Follow-up suggestion, non-blocking: there is now a disconnect between our internal naming ("job reaper") and the external flags ("hang detector"). We may wish to deprecate the old env in future to avoid confusion.

As agreed - leaving as-is for now. The description & name reflect this, while changing Flag & Env will break existing setups.

potential follow-up: The fact that we need to worry about this implies to me that we need a separate manager for provisioner job transitions similar to thewsbuild package.

Could be, are there any more scenarios we'd like to validate and put in a new issue?

I did up a table of all of the possible provisioner job states based on the four fields we use:

It'sprobably definitely out of scope of this PR, but I think there's a case to be made for drawing a state transition digram of provisioner jobs and figuring out which ones should never be possible. The ones I've commented on are my best guess at present.