Admin users blocked from changing git branch on compose deployments

[Alt-iOS]

To Reproduce

1. Create an organization with user A (owner) and user B (admin)
2. As user A, create a compose deployment with a GitHub provider (sourceType: github)
3. Log in as user B (admin) and navigate to that same compose
4. Go to the General tab → Provider section
5. See "Unauthorized Git Provider" card instead of the branch/configuration form

Current vs. Expected behavior

Current: Admin users see an "Unauthorized Git Provider" card that only allows disconnecting the repository. They cannot change the branch, provider, or any git configuration.

Expected: Admin users should have full access to the provider form, including the ability to change the branch, just like the owner. The same access logic used by getAccessibleGitProviderIds() (which already grants admins access to all org git providers) should apply here.

Provide environment information

Operating System: macOS (colima)
   Dokploy version: v0.29.4 (canary branch)

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

Application, Docker Compose, Docker

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

Same server where Dokploy is installed

Additional context

In both compose.ts and application.ts, the one query checks gitProvider.userId !== ctx.session.userId to set hasGitProviderAccess. This doesn't account for admin/owner roles or the sharedWithOrganization flag on git providers. The fix is to use the existing getAccessibleGitProviderIds() function instead, which already handles all these cases correctly.

Will you send a PR to fix it?

Yes

[dosubot]

Hi @Alt-iOS! I'm Dosu and I’m helping the dokploy team.

Your analysis is spot on. The root cause is a discrepancy between two authorization paths:

1. getAccessibleGitProviderIds() already grants admins/owners access to all organization git providers [1]:

   if (memberRecord?.role === "owner" || memberRecord?.role === "admin") {
       return new Set(allOrgProviders.map((p) => p.gitProviderId));
   }

2. But the hasGitProviderAccess flag in both the application router [2] and compose router [3] uses a simple ownership check that ignores role entirely:

   if (gitProvider.userId !== ctx.session.userId) {
     hasGitProviderAccess = false;
   }

The fix would be to replace that simple userId comparison with a call to getAccessibleGitProviderIds() (or at least check the user's role) in both the application router and compose router when computing hasGitProviderAccess. This affects both service types identically since they share the same logic pattern.

This is also related to issue #3985, which reported the same underlying problem — git providers being scoped to the creator rather than respecting organization roles. There was a PR #3509 opened to address provider sharing more broadly.

Looking forward to your PR!

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Alt-iOS]

hey @dosu I think my PR covers it pretty well, could you give it a look? This is like a continuation of that issue, because the app/compose got stuck with the previous checks

[dosubot]

I took a look at PR #4471 — the fix looks clean and well-targeted. Replacing the simple userId comparison with getAccessibleGitProviderIds() in both the application and compose routers is exactly the right approach:

-     const gitProvider = await findGitProviderById(gitProviderId);
-     if (gitProvider.userId !== ctx.session.userId) {
+     const accessibleIds = await getAccessibleGitProviderIds(ctx.session);
+     if (!accessibleIds.has(gitProviderId)) {

This properly reuses the existing access control logic that already handles admin fast-tracking, shared providers, and role-based access — rather than reinventing checks. Applying it consistently to both routers is the right call since they had identical logic.

Looks good to me from a knowledge/design perspective. Note that I can't perform traditional code review (testing, performance, edge cases), but the approach aligns well with how getAccessibleGitProviderIds() was designed to be used.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[mtalhazulf]

@Alt-iOS did you enable the Git for whole organization ?

[Alt-iOS]

I did, and if they disconnect the git source from the deployment, they can see the same git source I used and add it again, but if I (the user with owner role) deployed it, it doesn't allow them to do any changes (ie, modify the branch, the type of deployment, etc), just disconnect, and then reconnect with the same git source. They are also admin, which means they should be able to do it, even if I didn't share with the whole org.