Users Cannot Open Projects When They Don't Have Access to Default Environment

[Konders]

To Reproduce

1. Set up a project with at least two environments (say, production and development)
2. Make sure production is set as the default environment
3. Create a member user (not owner/admin) and give them access to the project, but only grant them access to the development environment - not production
4. Log in as that member user
5. Try to open the project from any of these places:
   • The projects list page (/dashboard/projects)
   • The search command (Cmd/Ctrl + J)
   • A direct URL to the project

You'll see the app tries to open the production environment, which the user doesn't have access to, and they either get an error or get redirected back to the home page. The project is effectively inaccessible even though they should be able to view it in the development environment.

The same issue happens when:

• Using the search command to find and open a project
• Clicking on a project card in the projects list
• Navigating directly to a project URL with an environment ID the user can't access

Current vs. Expected behavior

Current behavior:

The code assumes users can always access the default environment. When you open a project, it blindly tries to navigate to whatever environment has isDefault: true, without checking if that environment is actually in the user's accessible environments list.

For members with restricted access (which is a common use case - you might want devs to only see staging/dev environments), this completely breaks project access. They can see the project in the list, but clicking on it fails because the app tries to open an environment they don't have permission to view.

Expected behavior:

The app should be smarter about environment selection. If a user has access to the default environment, great - use that. But if they don't, we should fall back to the first environment they do have access to. This way, users with restricted permissions can still work with projects they're allowed to access, just in the environments they have permission for.

When someone tries to access a project via direct URL with an environment they can't access, we should redirect them to an accessible environment instead of just booting them back to the home page. It's a better UX and makes the permission system actually work as intended.

Provide environment information

Operating System:
  OS: Any (macOS, Linux, Windows)
  Arch: Any

Dokploy version: v0.26.3 (and earlier versions)

VPS Provider: Any

What applications/services are you trying to deploy?
Any - This is a UI/access control issue, not specific to any deployment type

Which area(s) are affected? (Select all that apply)

Application

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

The Problem

The issue shows up in three places in the codebase:

1. Search command (apps/dokploy/components/dashboard/search-command.tsx): When you search for a project and click it, it finds the default environment and navigates there. If that environment isn't accessible, the project just doesn't show up or fails silently.

2. Projects list (apps/dokploy/components/dashboard/projects/show.tsx): Same issue - clicking a project card tries to go to the production environment, creating a broken link if the user can't access it.

3. Server-side redirect (apps/dokploy/pages/dashboard/project/[projectId]/environment/[environmentId].tsx): When someone hits a project URL directly with an environment they can't access, the server correctly rejects it but just redirects to home. It should be smarter and redirect to an environment they can access.

Why This Happens

The backend is actually doing the right thing - the project.all query already filters environments for members based on their accessedEnvironments. So when a member queries projects, they only get back the environments they have permission to see.

The problem is the frontend code doesn't account for this. It still tries to find the default environment from the full list, not realizing that for members, the list is already filtered. So if the default isn't in their accessible list, the lookup fails.

The fix should be straightforward: since the environments array is already filtered for members, we just need to select from that filtered list. Try the default first (if it exists in the accessible list), otherwise grab the first one available.

Impact

This is a pretty significant issue for teams using the member/permission system. If you're trying to restrict access (which is a common security practice), this bug basically breaks project access for those users. The workaround is to give everyone access to production, which defeats the purpose of having granular permissions.

Severity: Medium-High - breaks core functionality for a legitimate use case

Affected Users: Any member users with environment-level access restrictions

I tested this on a local development setup with Node.js v20.19.6 and the latest codebase. The issue is reproducible across different environments since it's a logic issue in the frontend code.

Will you send a PR to fix it?

Yes