Fix permission checks on Client side

[rmartinoscar]

No description provided.

[coderabbitai]

📝 Walkthrough

Walkthrough

Two authorization checks were changed: the Settings page description field and its save flow now use ACTION_SETTINGS_DESCRIPTION instead of ACTION_SETTINGS_RENAME; the ScheduleTaskController delete action now requires ACTION_SCHEDULE_DELETE instead of ACTION_SCHEDULE_UPDATE.

Changes

Cohort / File(s)	Summary
Settings permission app/Filament/Server/Pages/Settings.php	Switched description field disablement and updateDescription authorization check from ACTION_SETTINGS_RENAME to ACTION_SETTINGS_DESCRIPTION.
Schedule task permission app/Http/Controllers/Api/Client/Servers/ScheduleTaskController.php	Changed delete method authorization check from ACTION_SCHEDULE_UPDATE to ACTION_SCHEDULE_DELETE.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant UI as Settings Page
    participant Auth as AuthorizationService
    participant Server

    User->>UI: open Settings
    UI->>Auth: check ACTION_SETTINGS_DESCRIPTION
    alt permitted
        UI-->>User: description editable
        User->>UI: submit description update
        UI->>Auth: authorize update (ACTION_SETTINGS_DESCRIPTION)
        Auth-->>UI: allow
        UI->>Server: save description
        Server-->>UI: success
    else forbidden
        UI-->>User: field disabled / save blocked
    end

Loading

sequenceDiagram
    participant Client
    participant API as ScheduleTaskController
    participant Auth as AuthorizationService
    participant Server

    Client->>API: DELETE /servers/:id/schedules/:task
    API->>Auth: check ACTION_SCHEDULE_DELETE for server
    alt permitted
        API->>Server: delete scheduled task
        Server-->>API: success
        API-->>Client: 204 No Content
    else forbidden
        API-->>Client: 403 Forbidden
    end

Loading

Pre-merge checks

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 66.67% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Description check	❓ Inconclusive	No pull request description was provided by the author, making it impossible to evaluate whether any description relates to the changeset.	Add a pull request description that explains the permission check fixes, their impact, and why these changes were necessary.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Fix permission checks on Client side' accurately describes the main changes: correcting permission check constants in two Client-side controllers for proper authorization gating.

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6774e5e and d03ba6a.

📒 Files selected for processing (1)

• app/Filament/Server/Pages/Settings.php (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

app/Filament/Server/Pages/Settings.php (3)

app/helpers.php (1)

• user (127-130)

app/Models/User.php (1)

• can (356-369)

app/Models/Permission.php (1)

• Permission (11-221)

🔇 Additional comments (2)

app/Filament/Server/Pages/Settings.php (2)

64-76: Description field now correctly gated by dedicated permission

Switching the Textarea disabled callback to Permission::ACTION_SETTINGS_DESCRIPTION aligns the UI with the dedicated description permission instead of rename, matching the intent of the separate settings.description capability. The config-based hidden() guard remains intact, so the field is only visible and editable when both feature and permission allow it.

---

278-307: Backend check now consistent with UI for description updates

updateDescription() now authorizes against Permission::ACTION_SETTINGS_DESCRIPTION while retaining the config('panel.editable_server_descriptions') guard, resolving the prior mismatch where the UI used the description permission but the backend enforced rename. This keeps client and server authorization in sync and avoids unnecessary 403s for users with description-only access.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d78c977 and 6774e5e.

📒 Files selected for processing (2)

• app/Filament/Server/Pages/Settings.php (1 hunks)
• app/Http/Controllers/Api/Client/Servers/ScheduleTaskController.php (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (2)

app/Http/Controllers/Api/Client/Servers/ScheduleTaskController.php (1)

app/Models/Permission.php (1)

• Permission (11-221)

app/Filament/Server/Pages/Settings.php (3)

app/helpers.php (1)

• user (127-130)

app/Models/User.php (1)

• can (356-369)

app/Models/Permission.php (1)

• Permission (11-221)

🔇 Additional comments (1)

app/Http/Controllers/Api/Client/Servers/ScheduleTaskController.php (1)

167-175: Verified: Using ACTION_SCHEDULE_DELETE for task deletion is the correct permission.

The Permission model confirms there is no separate ACTION_TASK_DELETE constant—tasks are managed under the schedule permission hierarchy. Using ACTION_SCHEDULE_DELETE appropriately gates this destructive operation at the schedule level and is consistent with the permission model design (schedule.read/create/update/delete). The change correctly tightens authorization semantics.