Jonathan
-
Posts
409 -
Joined
-
Last visited
-
Days Won
27
Everything posted by Jonathan
-
If only that were true
-
Seems you shouldn't be running a business. You knew this was going on, you knew you were taking a second job, you knew many things. You could've emailed your customers. You could've taken 5 minutes to send an email blast using Blesta's mass email plugin. You are full of excuses and no solutions. Take some responsibility and stop making excuses and for goodness sake don't start another "business" until you perhaps take some business management classes.
-
I do not recommend @ModulesGarden to anyone. Their code is sub-par and filled with security holes, most of which they brush off as insignificant. Anyone looking to use them please be careful.
-
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).
-
When provisioning a new service it's possible to end up with 2 services provisioned when only 1 should've been. If you manually activate the services on the pending service's "manage" page after the cron run has already started and queued it for provisioning (but not yet finished), both actions will provision said service. This appears to be a general bug and not tied to any module in particular as I can confirm it with both cPanel module and SolusVM module. I've noticed this situation since the 3.x branch.
-
Yep, of course we should be able to set it via the API calls as well. Simple text field on admin would suffice.
-
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.
-
+1
-
This is absolutely wonderful. -
+1
-
Yep the latter is ours. It's basically become a daily headache as we've progressed in 4.x in production.
-
+1 seeing this as well.
-
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.
-
Task isn't stuck. Resaving settings didn't help. It only occurs when the credit predates the invoice. If the credit is generated after the invoice, it gets applied.
-
Not quite sure what to say about this one, or how to recreate it. It seems to only happen if the credit balance is added to the account after the invoice is generated that it's not applying to. If the invoice existed prior to the credits it seems to work. The cron reports no issues and runs every 5 minutes. No client group setting is preventing this.
-
Bueller
-
Not running it on PHP7 yet. Trying to get a feel for it before messing with it or setting up a dev install.
-
Has anyone run into any PHP7-specific problems in v4?
-
This will be a good one.
-
Bump.
-
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.
-
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.
-
Looks like the functionality changed for ignoring the module. I sent you an email with details. I did find a workaround for now.
