Jonathan

Correct.
I'm not so sure that'd fix it.  Some services/modules can take several minutes to fully provision so I think this limbo problem is where the problem occurs (or would occur after your proposal).

+1000

Yep, of course we should be able to set it via the API calls as well.  Simple text field on admin would suffice.

Yep, of course we should be able to set it via the API calls as well.  Simple text field on admin would suffice.

+1000

One is the Blesta module reaching out to say a server to fetch certain information via an API or other means, and Blesta being responsible for dealing with suspension of a service for exceeding a plan's resources on the assumption the there's no system on the other end to do it, or that you're extending existing functionality and it's most logical for Blesta to deal with this.
A cron is needed to reach out and grab said information for parsing.

This is absolutely wonderful.

This is absolutely wonderful.

I think this is still related to the partial cents or .0001 or whatever that issue was.  So far I've only seen this happen where a partial cent is present anyway which causes trouble also when we manually apply it.

Not running it on PHP7 yet.  Trying to get a feel for it before messing with it or setting up a dev install.

This will be a good one.

Ran into a few cases of what appears to be described by CORE-1597 post-4.0 upgrade.  I believe there was some other patch having to do with this in 3.x but I can't seem to locate it.
Any ETA on when this seemingly-minor fix might be implemented?

Pro-rata invoices don't seem to include appropriate coupon discounts.  This can be consistently recreated by creating a service, adding a recurring coupon to it, and adjusting configurable options with pro-rate enabled resulting in a pro-rated invoice being generated but no coupon discount applied to it.

Yes, but I wanna say there was a hotfix as I clearly recall us running into it and y'all fixing it.  I dug through our emails and couldn't find it, but then I found this item.

Pro-rata invoices don't seem to include appropriate coupon discounts.  This can be consistently recreated by creating a service, adding a recurring coupon to it, and adjusting configurable options with pro-rate enabled resulting in a pro-rated invoice being generated but no coupon discount applied to it.

Looks like the functionality changed for ignoring the module.  I sent you an email with details.  I did find a workaround for now.

Looks like the functionality changed for ignoring the module.  I sent you an email with details.  I did find a workaround for now.

You'd be much better off using IP-based blocking instead of htpasswd.

You'd be much better off using IP-based blocking instead of htpasswd.

You'd be much better off using IP-based blocking instead of htpasswd.

Bump.  Still causing issues almost daily

It would be great if there were some events associated with contact addition, edit, and removal.  We for example could use this when syncing certain data within our ticket system (Kayako) regarding email assigned to the account and change it if necessary as well as keeping the proper emails tied into the same client organization there so that the tickets between their sub-accounts are viewable properly by other sub-accounts and the primary account, etc.

After an invoice is voided, if a one time payment link has been emailed out, it's still possible to "pay" this invoice which is voided using the one time payment link.
 
This results in confusion if this happens after an order has been placed, no paid for some time, canceled out by admins, the customer then pays and wonders why their service wasn't setup.
 
If a one time payment link is tied to what should be an unpayable invoice, an error should be displayed instead of allowing payment.  It's allowed even if the account is marked fraud which can pose an issue as well.

After an invoice is voided, if a one time payment link has been emailed out, it's still possible to "pay" this invoice which is voided using the one time payment link.
 
This results in confusion if this happens after an order has been placed, no paid for some time, canceled out by admins, the customer then pays and wonders why their service wasn't setup.
 
If a one time payment link is tied to what should be an unpayable invoice, an error should be displayed instead of allowing payment.  It's allowed even if the account is marked fraud which can pose an issue as well.

IMO a generic solution is the best way (assuming the button will still mention the name of the non-merchant somewhere) but an interim "quick-fix" to make everyone happy is fix the existing image.
 
A generic button is more of a feature request; swapping this image is more of a "bug" fix and the two items should be treated independently as such.