portability PR: new test

[josephjclark]

Testing something in CI for the portability PR

[josephjclark]

The PR fails because of this: OpenFn/kit#1497

I'll release the CLI and bump it on this branch

[josephjclark]

Ok the new test passes... but deploy tests with --new are failing. Did that break in lastest CLI? 😭

I'll have to pause and investigate this in a little bit.

[github-actions]

Both findings are confirmed as regressions introduced by this PR — the diffs explicitly show the removal of the project-scoping checks. Here is the final security review:

Security Review ⚠️

S0: Project-Scoped Data Access — FAIL

• lib/lightning_web/controllers/workflow_controller.ex:68-91 — check_permissions/3 previously required project.id == workflow.project_id, but this PR removed that clause and replaced it with a cond that only checks the caller's :edit_workflow / :run_workflow on the path's project. A user with those permissions on any project (e.g. their own sandbox) can now POST /projects/{their_project}/workflows/{victim_workflow_id}/runs and execute a job (or trigger) belonging to another project — using that project's credentials and reading the resulting dataclip via the response body. get_run_steps/2 and retry_run/2 in the same file correctly retain verify_run_belongs_to_project/2 (line 279), showing the intended pattern that create_run/2 is missing.

• lib/lightning_web/controllers/dataclip_controller.ex:113-175 (search/2) — the previous version passed project into NewManualRun.search_selectable_dataclips/5 for scoping; this PR dropped the project argument, and the new search_selectable_dataclips/4 (lib/lightning_web/live/workflow_live/new_manual_run.ex:22) calls Invocation.list_dataclips_for_job_with_cron_state(%Job{id: job_id}, ...) with no project_id filter. A user with :access_project on any project can supply another project's job_id and receive that project's dataclip results (names + IDs) and its next_cron_run_dataclip_id.

• lib/lightning_web/controllers/dataclip_controller.ex:199-220 (show_for_run/2) — this PR removed the previous guard Runs.get_for_project(run_id, project.id) == nil -> json(conn, %{dataclip: nil, run_step: nil}). The action now calls Invocation.get_first_dataclip_for_run_and_job(run_id, job_id) and get_first_step_for_run_and_job(run_id, job_id) (lib/lightning/invocation.ex:120,138), both of which filter only by run_id/job_id, no project. A member of any project can read dataclip bodies and step data from runs belonging to any other project. The sibling update_name/2 correctly retains check_dataclip_in_project/2, further confirming this is a regression.

These are all S0 (project scoping) regressions — the checks that previously prevented cross-tenant access were explicitly removed in this branch. Test coverage in test/lightning_web/controllers/workflow_controller_test.exs and test/lightning_web/controllers/dataclip_controller_test.exs only exercises "no access to the path project," not "access to path project but resource belongs elsewhere," so the gap is untested.