Tyson

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 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;

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.

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;

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(  

This is in v3.0.3.

The patch contains all patch versions since 3.0.0, hence the name "blesta-3.0.0-3.0.3".

This is in v3.0.3.

I was going off of yours and CubicWebs previous comments mentioning user_id, which is the value of $logged_in. However, Transactions::getTotalCredit() requires the client_id, and so you must first determine the client by fetching them via Clients::getByUserId().

I should mention that the Service Suspension email template was previously never used, and contained placeholder text and tags. When patching, the English, US version of this template will be updated. Be sure to adjust the template content as suitable for your company.

I was going off of yours and CubicWebs previous comments mentioning user_id, which is the value of $logged_in. However, Transactions::getTotalCredit() requires the client_id, and so you must first determine the client by fetching them via Clients::getByUserId().

This is in v3.0.3.

If you only have one row, it will not be removed.

Make sure the uploads directory is writable, as defined under [settings] -> [system] -> [General] -> [basic]. It should contain the absolute path to that directory.

The remaining untranslated definitions are not included in English for language packs. Blesta automatically defaults to a English definition if your language pack is missing it, so It would be redundant to include untranslated definitions from the translator.
 
And as Cody mentioned, translating the files manually can lead to other issues, like BOM. It also becomes very easy to create syntax errors, especially if you're not familiar with PHP and escaping characters, as well as sprintf-style variable replacement.

I'm not aware of a problem with service listings. Can you create a new thread about that issue? I'd like to keep this topic focused on the "customer-id" issue.

I stumbled on "total", "incredible" and a few other words, so I guess I'm a "kid".

I read this as "I'm sitting in the emergency room with my wife at the moment. Two 9mm shots to the kidney, and a bladder infection." For a second there, I thought you got shot. And then I wondered why you would be on the forums at a time like this.

I read this as "I'm sitting in the emergency room with my wife at the moment. Two 9mm shots to the kidney, and a bladder infection." For a second there, I thought you got shot. And then I wondered why you would be on the forums at a time like this.

It sounds like there may be 2 or 3 things going on here. The first error that says to use GET finally clicked with me. We had a similar issue in v2 a couple years ago because the live and test APIs behave differently. This is why some of you experienced a problem, while we couldn't duplicate it in our test environment. I believe the solution to this problem is the following:
 
Update /components/modules/logicboxes/apis/commands/logicboxes_customers.php (line 177)
return $this->api->submit("customers/search", $vars); change to:
return $this->api->submit("customers/search", $vars, "GET"); Then try creating another service and let me know what happens.
 
 
 
You unchecked the "Use Module" checkbox when you added the service? And it still attempted to add it using the module? That doesn't sound right.

This feature already exists. When a client logs in, their dashboard lists their invoices with an option to "View" each one. Clicking this will download the invoice PDF. Does this not happen for you?

The way it works is intended. Previously, it was a plain text field along with some other fields in Blesta, but those needed to by made into password-type fields. We plan to come back to this to improve how passwords are generated such that you would have an option to view the generated password.