Fix boolean validator on startup value

[rurueuh]

fixing #1829

[coderabbitai]

📝 Walkthrough

Walkthrough

The update method in the Startup page was modified to accept boolean values in addition to strings. A new local variable normalizes boolean states to string equivalents ('1'/'0') for use in validation, persistence, and logging operations.

Changes

Cohort / File(s)	Summary
Method signature update to accept boolean values app/Filament/Server/Pages/Startup.php	Updated update method signature to accept string|bool|null $state parameter instead of ?string $state. Introduced $stateForValidation variable to normalize boolean values to '1'/'0' strings. Validation now uses normalized state with early return on failure; all subsequent comparisons, activity logging, and notification content use the normalized state value.

Pre-merge checks

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The PR title "Fix boolean validator on startup value" directly relates to the code changes in the changeset. The summary indicates that the method was updated to accept string|bool|null instead of ?string, with a new normalization mechanism for boolean states, and improved validation logic. This aligns perfectly with the title's focus on fixing boolean validation for startup values. The title is concise, specific, and clearly communicates the primary change to a teammate reviewing the history.
Linked Issues Check	✅ Passed	The linked issue #1829 describes a problem where boolean startup values fail to update, specifically changes from true to false. The code changes directly address this by updating the method signature to accept string|bool|null, introducing a normalization mechanism that converts boolean states to strings ('1'/'0'), and improving validation logic with early return guards. All subsequent operations use the validated, normalized value. These changes align with the issue's requirement to enable users to change boolean startup values without errors.
Out of Scope Changes Check	✅ Passed	The code changes are isolated to the update method in app/Filament/Server/Pages/Startup.php and focus entirely on fixing the boolean validator issue described in issue #1829. The modifications include updating the method signature, introducing normalization logic for boolean states, and improving validation handling. All changes directly support the primary objective of fixing boolean startup value updates and show no unrelated modifications or scope creep.
Description Check	✅ Passed	The PR description references issue #1829, which is directly related to the changeset. While the description is minimal, it clearly indicates the linked issue about startup boolean value errors. The code changes address this issue by improving the boolean validation logic, so the description is meaningfully connected to the changeset. This meets the lenient criteria for description compliance.

---

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.}

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

app/Filament/Server/Pages/Startup.php (1)

188-192: Consider improving notification message for empty original values.

When $original is empty or null, the notification body displays " -> 1" which could be clearer. Consider formatting the message to handle this case more gracefully.

Apply this diff to improve the notification message:

 Notification::make()
     ->title(trans('server/startup.update', ['variable' => $serverVariable->variable->name]))
-    ->body(fn () => $original . ' -> ' . $stateForValidation)
+    ->body(fn () => ($original ?: trans('server/startup.empty')) . ' -> ' . $stateForValidation)
     ->success()
     ->send();

Note: This assumes a translation key exists or you can use a literal like '(empty)' instead.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e6bd6e4 and 533d619.

📒 Files selected for processing (1)

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

🧰 Additional context used

🧬 Code graph analysis (1)

app/Filament/Server/Pages/Startup.php (4)

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

• update (63-108)

app/Models/ServerVariable.php (2)

• ServerVariable (21-65)
• variable (61-64)

app/Facades/Activity.php (1)

• Activity (8-14)

app/Services/Activity/ActivityLogService.php (3)

• event (48-53)
• property (109-117)
• log (136-155)

🔇 Additional comments (2)

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

150-150: Signature change correctly addresses the boolean handling issue.

The updated signature now accepts boolean values directly, which aligns with the PR objective to fix boolean startup value updates.

---

155-155: Inconsistency found: API controller does not normalize booleans like Filament page does.

The Filament page (line 155) correctly normalizes boolean values to '1' and '0' strings before validation and storage. However, the API controller (app/Http/Controllers/Api/Client/Servers/StartupController.php lines 63-90) passes values directly without normalization: $request->validate(['value' => $variable->rules]) then stores $request->input('value') ?? ''.

This creates inconsistent behavior:

• Filament: true → '1' (validated and stored as string)
• API: true → stored as-is (could be boolean or depend on JSON encoding)

The Filament normalization logic itself is correct and consistently applied throughout. However, verify whether:

1. The API should also normalize booleans for consistency
2. The egg variable validation rules can handle raw boolean inputs from the API
3. This difference is intentional

[rurueuh]

I have read the CLA Document and I hereby sign the CLA

[Boy132]

Thanks but forcing a boolean to always be 0 or 1 will break some eggs when they expect false and true.
See my comment under the issue: #1829 (comment)