Jono

For step 4, you are correct in saying that Blesta does not support redirects for merchant gateways. Is there a reason you are not implementing this as a non-merchant gateway? Does the API not support that? Unfortunately non-merchant would allow the client to choose their payment method each time they are invoiced, so you could not do step 5. For step 5, well each currency is only allowed one merchant gateway so that should be happening automatically. Are you asking how to enable auto-debiting?

Probably the most straight forward solution would be to change the status of the ticket when you reply. Likely you would change it to "awaiting reply". Then after the client replies it will automatically be transitioned back to the "open" status.

@Blesta Addons When a proforma invoice is paid it is converted to an active invoice. When a proforma invoice is converted to an active invoice, its 'date_billed' is updated to the current date. 'date_billed' is what 'Invoiced Today' is based on. Would it be acceptable to not count proforma invoices as part of those 'Invoiced Today'?

Are you familiar with the tags employed by the email templates? You can find a list of tags for each email template in the docs here. Particularly the Invoice object tag under 'additional tags' sounds like it will be useful to you. For example you can include the invoice total in the email using the tag {invoice.total}

Okay I believe I identified the source of the problem and this should be a hotfix. Starting on line 1393 in app/models/invoices.php there should be this code: if ($i == 0 && ($dates = $this->Packages->getProrataDates( $service->pricing_id, $service->date_added . 'Z', $service->date_renews . 'Z' )) ) { Change that to: if ($i == 0 && $allow_pro_rata && ($dates = $this->Packages->getProrataDates( $service->pricing_id, $service->date_added . 'Z', $service->date_renews . 'Z' )) ) { This fix will be included in 4.2.1

Yep, it looks like it completed the upgrade fine.

I was referring to upgrading through the web interface, but using CLI works just as well. Well if you manipulated the widgets at all (e.g. reordering, collapsing, or expanding the widgets) after uploading the files, but before running the upgrade then the upgrade would not repopulate the widgets correctly. If you want to make sure the upgrade executed correctly, you can check your config file and search for 'session_ttl'. If that is in there then I'd say the upgrade went through fine.

You did actually run the upgrade at admin/upgrade, yes? This behavior was noted as a possibility and we worked to prevent it, so I'll look into what caused this. Anyhow, to fix this, you should be able to simply click the 'Manage Widgets' link on the left side of the admin home page, then arrange the widgets how you like. After that they should appear fine.

Currently that is not allowed in the system, since this would render those invoices and transactions inaccessible, thereby messing up reports for sales and revenue. The only way to do a full delete on a client who has these things would be to modify the database directly. NOTE: If you do decide to modify your database, absolutely back it up before making any changes.

Well it is possible, but only if the client has no transactions, invoices, or services associated with it. You can find the option on the client profile page, on the left nav, after expanding the option list by clicking "Show all actions".

So the email logs have a status of 'Sent'?

Are these being sent by email? Did you check the logs under Tools >> Logs >> Email to make sure they are actually being sent?

It is mentioned on lines 518, 1551, 1565, 1575, and 1936. cPanel.php handles updating account_count, but module.php handles selecting a server based on that account_count. Since the other thread about this error occurring on direct admin, I am thinking that the problem is with module.php or another related core file.

First release of v4?

And this error just started occurring now? When is the last time you upgraded and from what version? (BTW thanks for all your help on this).

I just thought of something. Is it possible that the service was created before the limit was reached and then provisioned after? The module row is selected when the service is created. If the service was created when the server was at 49/50, then another service was created bumping the server to 50/50, than this service would still be created on this server and would bump the server to 51/50. I imagine the easiest way to check this is to see if the bad behavior still happens when you create a service now. @evolvewh @cyandark

By 'assigned' you mean that they are in the 'Assigned Servers' section when edit a server group that is of course not a problem since that is simply how you assign the server to the group. As far as statistics, do you mean the 'Statistics' tab when editing the service? Because I'm fairly sure that info will be pulled exclusively from whatever server got assigned to that service.

Thank you much, hopefully this info will guide me to our problem.

Well it is not really an error since it "succeeds", it just doing the wrong thing, so we probably won't find any help in the logs. Maybe just some more info about your server group and package. Is it just two servers? Is there just one server group for the module? Have you confirmed that the package is using the server group rather than the individual server? Have you seen this in more than one module? Also just to make sure, have you modified any code in module.php?

I'd love to get this fixed in 4.2. Any info you guys can give me that might help me recreate this error would be greatly appreciated. @cyandark @evolvewh

What is the server/server group setup? And which module are you experiencing it on? (I think this is happening on modules that use the default module row selection but I just want to make sure).

If it turns out that it is not in junk I would do this. Create a test job and make sure the emails are set to be logged, run the cron, and check the email logs under Tools >> Logs >> Email to see if it shows these emails as sent.

Well the first thing I would check is whether the uploads/[company_id]/mass_mailer_files/ directory is writable.

Thus far I have been unable to determine a cause, or duplicate the error. I did however just receive a similar report here. I intend to take another look at this either today or some time this week.

Alright, I'll take another look at this issue then.