Centralized Custom Procedure Manager

[Devsome]

Is your feature request related to a problem? Please describe.

Some users of the SilkPanel CMS operate with custom filters between the game server and the database, requiring the use of specific MSSQL stored procedures. Currently, many actions (e.g., purchasing an item in the WebMall) are performed directly via Laravel DB inserts/updates, which are incompatible with such setups. There is no centralised way to replace these default actions with custom procedures or to test them.

Describe the solution you'd like

I would like a central management interface for custom stored procedures inside the Filament backend. This will be an extensible area where various CMS actions can gradually be switched from Laravel-native database operations to MSSQL stored procedures. The first action to be covered is the WebMall item purchase.

Backend (Filament Resource / Custom Page)

• A new menu item Custom Procedures in the Filament backend, designed to host multiple sub‑items later.
• An overview of "actions" that can be replaced by a stored procedure (e.g., "WebMall: Buy Item").
• Mapping configuration for each action:
  • Name / label of the action.
  • Status (enabled/disabled).
  • Stored procedure name in the database.
  • Parameter mapping: which Laravel variables (e.g., player_id, item_id, price_amount) map to which procedure parameters (order and name).
  • Option to define a fallback (use original Laravel logic if the procedure fails or does not exist).
• Testing area: a built‑in way to execute the configured procedure with example parameters directly from the backend to verify its behaviour.
• Logging: every call to a custom procedure (success/failure) should be logged for debugging.
• Global toggle: a setting (via Settings::) to enable/disable the entire custom procedures feature.

Starting point: WebMall item purchase

• The existing WebmallPurchaseService (or equivalent) that currently writes directly to the database should be replaceable by a user‑defined stored procedure.
• Parameters to pass to the procedure: @PlayerID (or @UserID), @CharacterID, @ItemID, @PriceType (Silk/Gold), @PriceAmount.
• The procedure must perform the same actions: check availability, deduct currency, deliver the item, and write a purchase log.
• If the procedure is missing or fails, the system should automatically fall back to the standard CMS logic.

Extensibility for future actions

• The system must be designed so that many other actions (e.g., "Create character", "Pay guild tax", "Craft item") can later be linked to custom procedures via the same interface.
• Use a unified contract/interface that every replaceable action must implement.

Describe alternatives you've considered

• Directly overriding Laravel models/controllers – too unstructured and hard to maintain, especially for multiple custom procedures per action.
• Third‑party package – the specific requirements (mapping, testing, fallback) are too custom for an off‑the‑shelf solution.
• No alternative – this feature is essential for users with custom database filters/procedures.

Additional context

• Tech stack: Laravel 13, Filament 5, Livewire, Alpine.js, Tailwind CSS.
• Database: MSSQL (sqlsrv driver).
• Executing procedures in Laravel: Use DB::statement("EXEC procedure_name ?", $params) or DB::select().
• Settings: Use the existing Settings:: facade (or a Filament settings page) for the global toggle.
• Existing code: WebMall already uses services like WebmallPurchaseService, SilkHelper, SilkroadItemService. These need to be extended to check for a custom procedure before performing the default logic.

Suggested files / structure

• app/Filament/Pages/CustomProcedures.php (Filament custom page for management)
• app/Services/ProcedureManager.php (central service to execute procedures)
• app/Contracts/ProcedurableAction.php (interface for replaceable actions)
• app/Actions/WebmallPurchaseAction.php (implementation for WebMall)
• database/migrations/create_procedure_mappings_table.php (columns: action, procedure_name, parameter_map, is_active, use_fallback)
• database/migrations/create_procedure_logs_table.php (logs of procedure calls)

Acceptance criteria:

• A "Custom Procedures" menu item appears in the Filament backend (admin only).
• The action "WebMall: Buy Item" can be selected and linked to a stored procedure.
• Parameter mapping is configurable (e.g., player_id → @UserID).
• A test button executes the configured procedure with example parameters and displays the result.
• When the procedure is active and enabled, it is used during a WebMall purchase; otherwise, the standard logic is used.
• A global setting "Enable Custom Procedures" turns the entire feature on/off.
• Failed procedure calls are logged and trigger the fallback logic.

Definition of Done for Copilot:

• Generate all necessary migrations, models, service classes, and the Filament custom page.
• Integrate the logic into the existing WebmallPurchaseService (check for a mapped procedure before executing default logic).
• Implement the ProcedureManager with methods like execute($action, $params).
• Ensure MSSQL stored procedures are called correctly with bound parameters (DB::statement with parameter binding).
• Add a test UI (Livewire component) inside the custom procedure page to execute procedures directly from the backend.