Tyson

The best way to manage test information is to separate it from your live system. In other words, use a developer installation to do the testing, and use your other installation as the live system.

What he said. By the way, when reporting bugs, be sure to include relevant data as described in How to Report a Bug so we can better assist and debug issues. This issue is not a bug, however, so I'm going to close this thread.

This wouldn't be a bug as your other installation is using a different key when hashing passwords. Your system key (set in the Blesta config file) needs to be the same, otherwise all encrypted data will be unrecoverable.

I assume you changed your IP address to zero octets? If so, you missed the one at the top. But besides the IP address, everything else looks fine. The error received from Plesk indicates you've reached the domain limit, so you'll need to look in Plesk under Subscriptions and Service Plans for more information, and to compare the number of domains being used for a subscription has not reached the limit available to the plan. You can view the maximum number of domains setting under Service Plans -> Resources tab in Plesk. You can also ask Plesk support as to what would cause you to receive this error when adding a subscription via the API: Can't create domain. Domain: nodomain876.co.uk [nodomain876.co.uk]. Reason: Failed to create 'nodomain876.co.uk'. The maximum number of domains allowed has been reached. (Error code 1)

Your screenshot illustrates why it said "Open (1)" but did not list any tickets: you have a ticket, but no ticket reply, hence all the null values. Every ticket should have at least one reply. It may not have been added due to the piping issue you had previously, but let us know if it happens again during normal operation.

You mean "Open (1)"? Sounds like the ticket you deleted was actually not the problem. You could run the SELECT queries I mentioned above, just replace "64" with "8999534". I'm curious to know what may have caused the ticket to be shown as open, but not listed.

Thanks. The problem you're having is due to Maxmind rejecting the order due to the score value. You'll probably want to increase the minimum rejection score setting.

Steps to duplicate?

That's a different ticket. Are you having the same problem with that one too?

No, there currently is no way to add additional delivery methods without updating core files. Providing a way for plugins to setup their own delivery methods would be ideal, but would require a lot of refactoring and abstraction to be added before that would be feasible. Someone did release vQmod for Blesta, however, which if implemented correctly, may allow you to include MetroFax without updating core code. I have not used vQmod for Blesta, but I have found it works pretty well for other software.

Unlikely it's a glitch, as I believe others have had a similar issue. But nonetheless, you can backup your database and the run this query to physically remove the ticket and all of its responses from the database: DELETE `support_tickets`.*, `support_replies`.* FROM `support_tickets` INNER JOIN `support_replies` ON `support_replies`.`ticket_id`=`support_tickets`.`id` WHERE `support_tickets`.`code`='64';

Interesting. Have you tried the support manager fix Cody included here? It's for a separate issue, but the query that fetches tickets has been updated. Curious if it has any affect on your ability to see that ticket.

Do any ticket reply details exist? You can run this to check SELECT `support_replies`.*, `support_tickets`.`department_id`, `support_departments`.`name` FROM `support_tickets` LEFT JOIN `support_replies` ON `support_replies`.`ticket_id` = `support_tickets`.`id` LEFT JOIN `support_departments` ON `support_departments`.`id` = `support_tickets`.`department_id` WHERE `support_tickets`.`code` =64;

Strange that the ticket number is only 2 digits instead of 7.. Are you piping in tickets from that support department email address with email in it from the old system? Did someone accidentally login to that email account and mark an email unread? What department is it assigned to? You can run this query to find out where it's assigned: SELECT `support_tickets`.`department_id`, `support_departments`.`name` FROM `support_tickets` LEFT JOIN `support_departments` ON `support_departments`.`id` = `support_tickets`.`department_id` WHERE `support_tickets`.`code` =64;

You're using the universal module, or a module that you created? If the former, you may be experiencing a blank page because you have error reporting off, but are actually experiencing this bug. If you take a look at my last response in that thread, I show you how to pre-patch your existing install to fix that problem.

Ah, glad you were able to find the cause.

I think you're under the illusion that a long list of bug fixes somehow equates to a lack of quality, however, I would infer that the opposite is true in most cases. As anyone who writes software will tell you, removing all bugs is next to impossible for almost all applications of any non-trivial size, and especially those used in different environments. I think it's a good thing to show each bug fix we implement for various reasons. If every customer ran away when they saw a list of bug fixes for a piece of software, it'd be easy for the vendor to simply not show a list of bug fixes and pretend they didn't exist in order to keep customers.

Per the source docs, if the user does not exist, boolean false is returned. Was that user deleted?

It's possible your custom changes have affected this, or that the page is still cached. You can remove the cache files from the /cache/ directory and give it another try.

This error comes from Plesk. If you can include your module logs (available under [Tools] -> [Logs]) related to this transaction we may be able to discover more about why you received this error. Feel free to omit any sensitive information in those logs before posting. When Blesta creates a service, the hosting plan should automatically be assigned to the subscription in Plesk. The fact you had to do this manually leads me to believe there may be a misconfiguration with the service plan such that the hosting plan is not being automatically linked with the subscription. A little more disconcerting is that Plesk gave you that error, but created the domain anyway. I'm not sure I understand that last part. Blesta creates a separate customer account (in Plesk) for each subscription (in Plesk) that is created when adding a service for a client (in Blesta). This was necessary in keeping identifying information available to Blesta for mantaining the service.

Could you show us the gateway logs associated with that transaction? Feel free to omit any sensitive data within it.

You'll have to give more information. Where does this message appear in the context of Blesta? What were you doing that caused it? The error seems pretty clear, however: "Invalid integer: 397.5". 397.5 is not an integer, but rather a float value. It's possible an integer was set, but the 50% coupon discount halved it into a float value and passed it to Stripe, but we need more info to find out where in the system this is happening.

Are you using v3.0.3? What does your Service Suspension email template look like for HTML/text content? If you're running v3.0.3, did you make sure to run the upgrade afterward? /admin/upgrade/ It sounds like you may not have actually run the upgrade, in which case that email template was never updated. If that's the case, then your error is caused by the placeholder content that existed previously, and which contained an invalid comparison operator "=", instead of "==". You'd need to run the upgrade.

This has been fixed in CORE-774 for v3.0.4. To patch yourself, update /app/models/invoices.php (line 885): Replace: // Increment the used quantity for all coupons used foreach ($coupons as $coupon_id => $coupon) $this->Coupons->incrementUsage($coupon_id); return $invoice_id; With: // Increment the used quantity for all coupons used foreach ($coupons as $coupon_id => $coupon) $this->Coupons->incrementUsage($coupon_id); // Update invoice totals $this->updateTotals($invoice_id); return $invoice_id;

No, you shouldn't be required to have service options set. This is a bug--assigned as CORE-778 and already fixed for v3.0.4. Thanks for taking the time to confirm it was isolated to v3.0.3. To patch yourself, update /components/modules/universal_module/universal_module.php (line 1118): Change for ($j=0, $i=0; $i<count($vars['service_fields']['label']); $i++) { $meta[] = array( To: for ($j=0, $i=0; $i<count($vars['service_fields']['label']); $i++) { if ($vars['service_fields']['name'][$i] == "") continue; $meta[] = array(