Members with service access get 401 on schedule deployments (deployment.allByType passes scheduleId to checkServicePermissionAndAccess)

[ynk-ptorres]

To Reproduce

Describe the bug

In apps/dokploy/server/api/routers/deployment.ts, the allByType procedure runs its access check with:

await checkServicePermissionAndAccess(ctx, input.id, {
  deployment: ["read"],
});

checkServicePermissionAndAccess expects a service id (application/compose). For type=application and type=compose this is correct, since input.id is the service id. But for type=schedule, input.id is the scheduleId, not a service id. The function can't resolve a member's access from a scheduleId, so it throws UNAUTHORIZED.

As a result, any non-owner/non-admin member gets a 401 when opening a schedule's "Deployments", even when they have full access to the environment/service the schedule belongs to.

The sibling procedures in the same file (killProcess, removeDeployment, readLogs) handle schedule deployments correctly — they resolve the underlying service first:

const serviceId = deployment.applicationId || deployment.composeId;
if (serviceId) {
  await checkServicePermissionAndAccess(ctx, serviceId, { /* ... */ });
} else if (deployment.schedule?.serverId) {
  // organization-level check
}

allByType skips this resolution step. This is the same class of access-check bug as #4469.

To Reproduce

1. Create a project with an environment (e.g. production) containing an application service.
2. Add a schedule (scheduleType: application) to that application.
3. Create a Member user (not owner/admin) and grant them access to that environment/service.
4. Log in as the member → open the application → Schedules tab → click a schedule's Deployments.
5. The dialog hangs on "Loading deployments..." and GET /api/trpc/deployment.allByType?...&type=schedule returns 401 Unauthorized.

Current vs. Expected behavior

Current: Members with access to the schedule's underlying service still get 401 on deployment.allByType for type=schedule. Setting the schedule's userId to the member does not help. Only promoting the user to owner/admin works (they bypass the check).

Expected: A member with read access to the schedule's underlying service should be able to view the schedule's deployment history, consistent with how they can already view application/compose deployments.

Proposed fix

In allByType, when input.type === "schedule", resolve the schedule to its applicationId/composeId and pass that to checkServicePermissionAndAccess (mirroring killProcess/readLogs); for serverId-based schedules, do the organization check like allByServer. Same approach recommended for #4469 — use the helper that already handles all role/access cases.

Environment

• Dokploy version: v0.28.8, self-hosted (Docker Swarm). The same code path is present in the current canary branch.

Which area(s) are affected?

Schedules, Deployments, Permissions

Will you send a PR to fix it?

No

Current vs. Expected behavior

Current: A member (non owner/admin) who has access to the environment/service that a schedule belongs to gets a 401 (UNAUTHORIZED) when opening that schedule's "Deployments". The dialog stays on "Loading deployments..." indefinitely, and GET /api/trpc/deployment.allByType?...&type=schedule returns 401. Setting the schedule's userId to the member does not help. Only promoting the user to owner/admin (which bypasses the access check) makes the deployments load.

Expected: A member with read access to the schedule's underlying service should be able to view that schedule's deployment history, consistent with how the same member can already view application/compose deployments.

Provide environment information

Operating System:
  OS: <tu OS del host, ej. Ubuntu 22.04 / Debian 12>
  Arch: <ej. x86_64>

Dokploy version: v0.28.8 (self-hosted, Docker Swarm, single manager node)


What applications/services are you trying to deploy?
Not deployment-type specific — this is an access-control issue when viewing the
deployment history of a Schedule (scheduleType: application) attached to an
application service.

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

No response

Will you send a PR to fix it?

Yes