Leaderboard

add this line to your configuration.php it will go back to normal behavior $allow_adminarea_invoice_mutation = true;

Update PHP first to a version that's compatible with BOTH the existing and the new version to be installed. Make sure the existing system health page reports everything is OK. Then try updating WHMCS. Once update is successful, and you have a working WHMCS, you can attempt to update PHP again to the latest supported version, for whatever version of WHMCS you are upgrading to.

Hello Everyone, We are currently using WHMCS version 9.0.1 and after upgrading, we have noticed two issues related to invoice management and staff permissions. We would appreciate clarification from the community. Unpaid Invoice Cannot Be Edited When trying to modify an unpaid invoice, the system shows: "This is an Unpaid Invoice. You cannot modify an Invoice that is Unpaid." Previously, we were able to edit unpaid invoices in cases of pricing corrections, tax adjustments, or client-requested changes. We are unable to find any setting that allows editing unpaid invoices in version 9.0.1. Is this now the intended behavior? Is there any supported method to allow editing unpaid invoices without marking them as paid first? Cancel Invoice Permission Requires Delete Permission We assign the "Cancel Invoice" permission to specific employees so they can cancel invoices when there are billing errors or mismatches. The cancel action keeps proper logs and maintains an audit trail, which is important for internal control. However, it appears that the Cancel Invoice permission now requires the Delete Invoice permission to function. This forces us to grant both Cancel and Delete permissions. This creates a concern because if Delete permission is given, staff may delete invoices instead of cancelling them. Deleted invoices do not provide the same level of audit visibility, and it becomes difficult to track what was removed and why. Our requirement is to allow invoice cancellation with proper logging, but not allow invoice deletion. Has anyone else faced this in 9.0.1? Is this expected behavior, or is there a way to separate Cancel and Delete permissions properly? Looking forward to feedback from the community. Thanks in advance.

And it was...?

Hi Still waiting on the answer, also. I guess I need to open a ticket then

Key Features List Our WhatsApp Gateway: Authentication and User Management: Login, registration, and logout using CodeIgniter Shield. User group system (admin & user). User profile management. User Dashboard: Subscription overview (active plan, remaining days, message/device limits). Usage statistics (messages sent, devices connected). Alerts for expired subscriptions or reached limits. API token management for external access. WhatsApp Integration: Multi-session device management (multiple WhatsApp accounts per user). Sending of text and media messages (images, etc.). QR code scanning to connect WhatsApp devices. Message logging (delivery status, WhatsApp message ID). Message limit checks based on subscription plans. Subscription and Plan System: Various plans with device and message limits. Usage tracking (messages sent, active devices). Subscription management (active, expired). Plan upgrade/downgrade. Admin Panel: User management (create, edit, delete users). Assign groups and plans to users. RESTful API: Endpoints for sending WhatsApp messages via token. Integration with Node.js backend for WhatsApp operations. Modules: Invoices, Orders, Payments. Multi-language support (English, Indonesian, Spanish, UAE/Arabic, Chinese). Node.js Backend (whatsapp-web.js): Node.js server for running WhatsApp clients. Multi-session support with LocalAuth. Handling of QR codes, connections, and message/media sending. Logging and error handling. Security and Logging: Input validation and CSRF protection. Message and user activity logging. Environment variables for sensitive configuration (NODE_URL, etc.).

it doesn't use an email template and that email is hard-coded internally to WHMCS... two thoughts.. if you are using PHP Mail for your email settings, I think it will show the client's IP in the header - specifically in the X-PHP-Script setting output... I can't recall if the same applies when using SMTP to send. perhaps you could add just jQuery/JS to the form to add the client's IP value to the message string before it sends to WHMCS ? all that said, there's nothing to stop a user hiding their IP by any number of methods - so there's no guarantee that any value you receive for their IP address, by any method, would be accurate.

Hey @pikerr are you sending to a department or to an email address?