- Add gift card redemption feature
- Resolve custom range selection issue in overview
- Allow log page size to be modified
- Add subscription path change notification
- Improve dynamic node rate feature
- Support markdown documentation display for plugins
- Reduce power reset service logging
- Fix backend version number not updating after update
Fix an issue where entering a non-existent invite code during registration would result in an unclear HTTP code 0 error. Now, the system properly validates the invite code and returns a clear error response if the code does not exist.
- Add HookManager::filter('client.subscribe.servers') hook in ClientController::subscribe()
- Allow plugins to inject custom servers into subscription responses
- Update protocol classes to support extended server configurations
- Enable dynamic server list modification before protocol processing
A TypeError occurred when filtering the user list by the `total_used` computed attribute. The `applyQueryCondition` method expected a string for the field name, but received an `Illuminate\Database\Query\Expression` object from `DB::raw`.
This commit updates the `buildFilterQuery` method to check if the query field is an `Expression` instance. If so, it now uses `whereRaw` to apply the filter, preventing the type error and enabling filtering on computed fields. For standard string fields, it continues to use the original `applyQueryCondition` logic.Fix: Handle raw DB expressions in user filter
A TypeError occurred when filtering the user list by the `total_used` computed attribute. The `applyQueryCondition` method expected a string for the field name, but received an `Illuminate\Database\Query\Expression` object from `DB::raw`.
This commit updates the `buildFilterQuery` method to check if the query field is an `Expression` instance. If so, it now uses `whereRaw` to apply the filter, preventing the type error and enabling filtering on computed fields. For standard string fields, it continues to use the original `applyQueryCondition` logic.Fix: Handle raw DB expressions in user filter
A TypeError occurred when filtering the user list by the `total_used` computed attribute. The `applyQueryCondition` method expected a string for the field name, but received an `Illuminate\Database\Query\Expression` object from `DB::raw`.
This commit updates the `buildFilterQuery` method to check if the query field is an `Expression` instance. If so, it now uses `whereRaw` to apply the filter, preventing the type error and enabling filtering on computed fields. For standard string fields, it continues to use the original `applyQueryCondition` logic.Fix: Handle raw DB expressions in user filter
A TypeError occurred when filtering the user list by the `total_used` computed attribute. The `applyQueryCondition` method expected a string for the field name, but received an `Illuminate\Database\Query\Expression` object from `DB::raw`.
This commit updates the `buildFilterQuery` method to check if the query field is an `Expression` instance. If so, it now uses `whereRaw` to apply the filter, preventing the type error and enabling filtering on computed fields. For standard string fields, it continues to use the original `applyQueryCondition` logic.Fix: Handle raw DB expressions in user filter
A TypeError occurred when filtering the user list by the `total_used` computed attribute. The `applyQueryCondition` method expected a string for the field name, but received an `Illuminate\Database\Query\Expression` object from `DB::raw`.
This commit updates the `buildFilterQuery` method to check if the query field is an `Expression` instance. If so, it now uses `whereRaw` to apply the filter, preventing the type error and enabling filtering on computed fields. For standard string fields, it continues to use the original `applyQueryCondition` logic.Fix: Handle raw DB expressions in user filter
A TypeError occurred when filtering the user list by the `total_used` computed attribute. The `applyQueryCondition` method expected a string for the field name, but received an `Illuminate\Database\Query\Expression` object from `DB::raw`.
This commit updates the `buildFilterQuery` method to check if the query field is an `Expression` instance. If so, it now uses `whereRaw` to apply the filter, preventing the type error and enabling filtering on computed fields. For standard string fields, it continues to use the original `applyQueryCondition` logic.Fix: Handle raw DB expressions in user filter
A TypeError occurred when filtering the user list by the `total_used` computed attribute. The `applyQueryCondition` method expected a string for the field name, but received an `Illuminate\Database\Query\Expression` object from `DB::raw`.
This commit updates the `buildFilterQuery` method to check if the query field is an `Expression` instance. If so, it now uses `whereRaw` to apply the filter, preventing the type error and enabling filtering on computed fields. For standard string fields, it continues to use the original `applyQueryCondition` logic.Fix: Handle raw DB expressions in user filter
A TypeError occurred when filtering the user list by the `total_used` computed attribute. The `applyQueryCondition` method expected a string for the field name, but received an `Illuminate\Database\Query\Expression` object from `DB::raw`.
This commit updates the `buildFilterQuery` method to check if the query field is an `Expression` instance. If so, it now uses `whereRaw` to apply the filter, preventing the type error and enabling filtering on computed fields. For standard string fields, it continues to use the original `applyQueryCondition` logic.Fix: Handle raw DB expressions in user filter
A TypeError occurred when filtering the user list by the `total_used` computed attribute. The `applyQueryCondition` method expected a string for the field name, but received an `Illuminate\Database\Query\Expression` object from `DB::raw`.
This commit updates the `buildFilterQuery` method to check if the query field is an `Expression` instance. If so, it now uses `whereRaw` to apply the filter, preventing the type error and enabling filtering on computed fields. For standard string fields, it continues to use the original `applyQueryCondition` logic.
Updated the `admin_setting` and `admin_settings_batch` helpers to retrieve the `Setting` instance from the service container. This fixes a fatal error and ensures correct behavior in a Laravel Octane environment by preventing the use of stale, shared static instances.
- Add HasPluginConfig trait and PluginController base class
- Integrate guest_comm_config hook in CommController for plugin frontend config injection
- Add user creation functionality to UserService and fix null value handling
- Enhance AbstractPlugin.getConfig() with key parameter support
- Multiple service layer optimizations and architecture improvements
- Implement reCAPTCHA v3 with score-based validation
- Add Cloudflare Turnstile as captcha alternative
- Create reusable CaptchaService for unified validation
- Support switching between recaptcha, recaptcha-v3, and turnstile
- Maintain backward compatibility with existing configurations
- Fix known bugs in user, plan, and server modules
- Standardize code formatting and structure
- Optimize database queries and model relationships
- Improve request validation and error handling
- Update admin controllers for better consistency
- feat: add plan price validation
- feat: make traffic packages stackable
- feat: add commission and invite info to admin order details
- feat: apply email whitelist to verification code API
- fix: subscription link copy compatibility for non-HTTPS
- fix: resolve route editing 500 error in certain cases
- refactor: restructure traffic reset logic
- Add system log cleanup functionality with batch processing
- Optimize v2_settings table performance by unifying value storage
- Add comprehensive client support list for one-click subscription
- Fix QR code subscription links for specific node types
- Fix route addition issues in admin management panel
- Enhance admin system controller with log management APIs
- Replace request->merge() with request->attributes->set() in Server middleware to avoid polluting user input
- Add getNodeInfo() helper method in UniProxyController for cleaner node info access
- Update all node_info references to use the new attribute-based approach
- Refactor node filtering logic to correctly handle client base_version requirements.
- Set appropriate Content-Type header for subscription responses.
- Add support for hop_interval configuration in hysteria2 node delivery.
- Implemented node load status submission in UniProxyController with dynamic cache expiration based on server push interval.
- Added log filtering capability in the admin panel for better log management and analysis.
