Skip to content

Conversation

@PalmarHealer
Copy link
Contributor

  • Introduced create_new configuration to control automatic allocation behavior.
  • Updated allocation service logic to respect the create_new toggle.
  • Enhanced panel settings UI to include the new create_new toggle option.
  • Added helper text for better clarity on configuration options.

Supersedes #1852

- Introduced `create_new` configuration to control automatic allocation behavior.
- Updated allocation service logic to respect the `create_new` toggle.
- Enhanced panel settings UI to include the new `create_new` toggle option.
- Added helper text for better clarity on configuration options.
@coderabbitai
Copy link

coderabbitai bot commented Nov 9, 2025

📝 Walkthrough

Walkthrough

Adds a runtime feature flag and admin toggle to control whether the allocation service may create new allocations when no unassigned allocation exists; the config, translations, Filament settings UI, and allocation service behavior are updated accordingly.

Changes

Cohort / File(s) Summary
Settings UI & Translations
app/Filament/Admin/Pages/Settings.php, lang/en/admin/setting.php
Added new boolean toggle PANEL_CLIENT_ALLOCATIONS_CREATE_NEW to misc settings (visible only when allocations are enabled) and added translation keys misc.auto_allocation.create_new and misc.auto_allocation.create_new_help.
Configuration
config/panel.php
Added client_features.allocations.create_new config option backed by PANEL_CLIENT_ALLOCATIONS_CREATE_NEW (default true).
Allocation Service
app/Services/Allocations/FindAssignableAllocationService.php
Service now reads client_features.allocations.create_new and: returns an existing unassigned allocation if found; if none found, creates a new allocation when enabled or throws NoAutoAllocationSpaceAvailableException when disabled. Docblock/comments updated.

Sequence Diagram(s)

sequenceDiagram
    participant Caller
    participant Service as FindAssignableAllocationService
    participant Repo as AllocationRepo
    participant Config

    Caller->>Service: findAssignableAllocation()
    Service->>Repo: query for unassigned allocation
    Repo-->>Service: allocation or null

    alt Unassigned allocation exists
        Service-->>Caller: return allocation
    else No unassigned allocation
        Service->>Config: read client_features.allocations.create_new
        Config-->>Service: boolean

        alt create_new = true
            rect rgb(200,220,255)
            Note over Service,Repo: create allocation within configured port range
            Service->>Repo: create allocation
            Repo-->>Service: new allocation
            Service-->>Caller: return allocation
            end
        else create_new = false
            rect rgb(255,220,200)
            Note over Service: throw NoAutoAllocationSpaceAvailableException
            Service-->>Caller: throw exception
            end
        end
    end
Loading

Possibly related PRs

Pre-merge checks

✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately summarizes the main change: adding a toggle for automatic allocation creation in panel settings, which is reflected across all modified files.
Description check ✅ Passed The description is directly related to the changeset, listing four specific modifications that align with the actual changes made to settings, service logic, and translations.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

📜 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 a886e1d and 0034868.

📒 Files selected for processing (2)
  • app/Filament/Admin/Pages/Settings.php (1 hunks)
  • app/Services/Allocations/FindAssignableAllocationService.php (3 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • app/Services/Allocations/FindAssignableAllocationService.php
  • app/Filament/Admin/Pages/Settings.php

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

  • Provide your own instructions using the high_level_summary_instructions setting.
  • Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
  • Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

  1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
  2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
  3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
  4. 📊 Contributor Summary — Include a Markdown table showing contributions:
    | Contributor | Lines Added | Lines Removed | Files Changed |
  5. ✔️ Additional Notes — Add any extra reviewer context.
    Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.


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

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

@PalmarHealer PalmarHealer marked this pull request as ready for review November 9, 2025 23:11
@PalmarHealer
Copy link
Contributor Author

@coderabbitai review

@coderabbitai
Copy link

coderabbitai bot commented Nov 9, 2025

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
app/Services/Allocations/FindAssignableAllocationService.php (1)

56-67: Consider restructuring for clarity.

The logic is functionally correct, but the control flow could be more explicit. The comment on line 61 states "If create_new is enabled, create a new allocation if none available," but line 62 also handles the case where an allocation already exists (via the null coalescing operator).

Consider this more explicit structure:

-        // If create_new is disabled, only pick from existing allocations
-        if (!$createNew && !$allocation) {
-            throw new NoAutoAllocationSpaceAvailableException();
-        }
-
-        // If create_new is enabled, create a new allocation if none available
-        $allocation = $allocation ?? $this->createNewAllocation($server);
+        if (!$allocation) {
+            // If create_new is disabled, only pick from existing allocations
+            if (!$createNew) {
+                throw new NoAutoAllocationSpaceAvailableException();
+            }
+            
+            // Create a new allocation if create_new is enabled
+            $allocation = $this->createNewAllocation($server);
+        }

This makes it clearer that:

  1. We only enter the conditional block when no allocation exists
  2. We either throw an exception or create a new allocation based on the setting
  3. If an allocation already exists, we skip the entire block
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5c3b091 and b67ada7.

📒 Files selected for processing (4)
  • app/Filament/Admin/Pages/Settings.php (1 hunks)
  • app/Services/Allocations/FindAssignableAllocationService.php (3 hunks)
  • config/panel.php (1 hunks)
  • lang/en/admin/setting.php (1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-12T17:33:57.388Z
Learnt from: lancepioch
Repo: pelican-dev/panel PR: 1595
File: app/Services/Servers/ServerCreationService.php:182-184
Timestamp: 2025-08-12T17:33:57.388Z
Learning: In the Pelican Panel codebase, when updating allocations to assign them to servers, the preferred pattern is to use whereNull('server_id'), lockForUpdate(), and direct property assignment with save() rather than mass update methods, to prevent race conditions and mass-assignment issues while ensuring model events fire properly.

Applied to files:

  • app/Services/Allocations/FindAssignableAllocationService.php
🧬 Code graph analysis (1)
app/Services/Allocations/FindAssignableAllocationService.php (1)
app/Models/Server.php (1)
  • allocation (277-280)
🔇 Additional comments (4)
config/panel.php (1)

36-36: LGTM!

The new configuration option is properly structured, follows the existing pattern, and defaults to true to maintain backward compatibility with current behavior.

app/Filament/Admin/Pages/Settings.php (1)

625-636: LGTM!

The new toggle is well-integrated and follows existing patterns in the settings UI. The visibility constraint (only shown when allocations are enabled) is appropriate, and all UI elements (label, helper text, icons, colors, state cast) are properly configured.

app/Services/Allocations/FindAssignableAllocationService.php (2)

24-35: LGTM!

The updated docblock clearly explains the new behavior: attempting to find existing allocations first, then either creating new ones (if enabled) or throwing an exception (if disabled).


42-42: LGTM!

The configuration read properly defaults to true, maintaining backward compatibility with existing behavior.

@rmartinoscar
Copy link
Member

Doesn't seem worth adding, if an allocation is created by an admin it will be locked by default already.

@PalmarHealer
Copy link
Contributor Author

PalmarHealer commented Nov 10, 2025

But if I provide a large port range and want to exclude certain ports from being assigned, this comes in very handy because I can create the assignable ports beforehand and then use this option.

see more Or, in my use case, I have two nodes and can have different port ranges for each one by creating the ports beforehand and then giving a range that includes all and using this option to prevent ports I don't want from being used.

I know it's a small change and can be seen as not needed, but I would benefit greatly from this, and I think others can appreciate it as well.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
app/Services/Allocations/FindAssignableAllocationService.php (1)

52-59: Consider using the preferred allocation assignment pattern (pre-existing).

Based on learnings from the codebase, the preferred pattern for assigning allocations to servers includes using lockForUpdate() when querying and direct property assignment instead of mass updates. This prevents race conditions and ensures model events fire properly.

While this is pre-existing code (not introduced by this PR), consider refactoring to:

$allocation = Allocation::withoutGlobalScopes()
    ->where('node_id', $server->node_id)
    ->when($server->allocation, function ($query) use ($server) {
        $query->where('ip', $server->allocation->ip);
    })
    ->whereNull('server_id')
    ->lockForUpdate()  // Add lock
    ->inRandomOrder()
    ->first();

// ... (conditional logic) ...

// Replace line 69
$allocation->server_id = $server->id;
$allocation->save();

Based on learnings

Also applies to: 69-69

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b67ada7 and a886e1d.

📒 Files selected for processing (2)
  • app/Filament/Admin/Pages/Settings.php (1 hunks)
  • app/Services/Allocations/FindAssignableAllocationService.php (3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • app/Filament/Admin/Pages/Settings.php
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-12T17:33:57.388Z
Learnt from: lancepioch
Repo: pelican-dev/panel PR: 1595
File: app/Services/Servers/ServerCreationService.php:182-184
Timestamp: 2025-08-12T17:33:57.388Z
Learning: In the Pelican Panel codebase, when updating allocations to assign them to servers, the preferred pattern is to use whereNull('server_id'), lockForUpdate(), and direct property assignment with save() rather than mass update methods, to prevent race conditions and mass-assignment issues while ensuring model events fire properly.

Applied to files:

  • app/Services/Allocations/FindAssignableAllocationService.php
🧬 Code graph analysis (1)
app/Services/Allocations/FindAssignableAllocationService.php (1)
app/Models/Server.php (1)
  • allocation (277-280)
🔇 Additional comments (4)
app/Services/Allocations/FindAssignableAllocationService.php (4)

24-28: LGTM! Clear documentation of the new behavior.

The updated docblock accurately describes the new create_new toggle behavior and clarifies the control flow.


61-64: LGTM! Logic correctly implements the toggle behavior.

The conditional correctly prevents automatic allocation creation when the toggle is disabled and no unassigned allocations are available.


45-46: LGTM! Comments accurately reflect the new behavior.

The updated inline comments clearly document the conditional logic based on the create_new toggle.

Also applies to: 66-66


42-42: Config key verified and properly defined.

The config key panel.client_features.allocations.create_new is correctly defined in config/panel.php:36 with the default value true, matching the implementation. No issues found.

@rmartinoscar
Copy link
Member

rmartinoscar commented Nov 27, 2025

@PalmarHealer Please resolve conflicts.

@Boy132 Boy132 merged commit 6c02f9a into pelican-dev:main Dec 1, 2025
25 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Dec 1, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants