OpenFn / OpenFn/lightning

Sandbox collaborators who aren't on the parent project can't see the sandbox in the main projects menu

Open
#5,007 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Elixir
Stars
296
Forks
86
Avg merge
1d 13h
Merged PRs (30d)
50

Description

Summary

You can add a user as a collaborator to a sandbox without adding them as a collaborator on the sandbox's parent project — this is expected behaviour. However, that user then can't find the sandbox in the main menu. It does appear correctly in the CMD+P quick switcher, so the permission grant and CMD+P search both work as expected; the main menu is the only place this breaks.

Steps to reproduce
  1. Create a sandbox within a project.
  2. Add a collaborator to the sandbox who is not a collaborator on the parent project.
  3. Log in as that collaborator.
  4. The sandbox does not appear in the main menu. (It does appear via CMD+P.)
Expected behaviour

A user with sandbox-level access should be able to discover and open that sandbox from the main menu, consistent with how it already works in CMD+P. Sandbox access independent of parent-project access is intentional and should remain possible — nothing about the fix should require adding the collaborator to the parent project or restricting collaborators to parent-project members.

Impact

This is a discoverability gap rather than broken access — the user does have a working path to the sandbox via CMD+P — but the main menu is the primary/expected navigation surface, and its omission means most users won't find a sandbox they have legitimate access to.

Product question

The main menu currently nests sandboxes under their parent project, so a user with no access to the parent never sees the sandbox listed there — even though they have valid access to it. The menu should surface sandboxes the user can access on their own, separate from that nesting, so it matches what CMD+P already does.

This should be solved on the navigation side only. The permission model is correct as-is: sandbox access without parent-project access is intentional, and the fix should not add the collaborator to the parent project or otherwise change how access is granted.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing how the main projects menu builds its sandbox list, then compare that path with the CMD+P quick switcher, where the sandbox is already discoverable. Keep the existing sandbox-level permission behavior unchanged; done means an authorized sandbox collaborator can find and open the sandbox from the main menu without parent-project access.

Written by the indexing model from the issue text.

Assessment

Domain
frontend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
65/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.