Tyson

Are you using v3 or v2.5 of Blesta? We're assuming v3, in which case you would take a look at the source documentation, SDK, and Invoices::add().

Yes, this is intentional for the time being. It will be updated, IIRC, to disallow the module from being uninstalled if it has services or packages associated with it. This poses a problem, however, of never being able to uninstall a module if a service uses it, because a service could not be disassociated with it; similarly for packages. So there are a few considerations we need to resolve before adding this in.

Glad its working for you now. Only possible explanation I can think of is that the Create Invoice task was disabled, and you only just recently enabled it. Besides that, there's not enough information to describe why it wasn't working for you.

Was it related to this thread?

Do you still see the message "Invoices have not been automatically created via cron in the past 24 hours."? Is the Create Invoices task last run date still November 17? If either are true, then it doesn't make sense, because the query you ran on the database returns no results, meaning no tasks have failed to run recently.

Have you made any changes on or before Nov 17 at 4:38 pm? Usually something like this is caused by an error, perhaps from code with syntax errors, or an invalid object reference. If you've updated code or altered the database manually, it may have affected this. But to see what the error is, you'll probably need to check the PHP error logs or run a test. The test would be to: 1. Check the database for the latest entry for when this task has failed. The run_id for this task is probably 1. SELECT * FROM `log_cron` WHERE `run_id` !=0 AND `end_date` IS NULL ORDER BY `start_date` DESC; 2. Delete the most recent record (at the top of the list). This makes it so that the next time the cron runs, it will attempt to run this task. 3. Run the cron manually through [settings] -> [system] -> [Automation] -> Run Cron Manually. You must do this before the cron runs automatically. 4. The cron will likely stall out due to error when it attempts this cron task, and the error should be displayed. You may need error reporting on to see it.

The server Blesta is running on.

You do not have Soap available on your server. You'll need to make sure libxml is installed with PHP configured to --enable-soap. See installation/requirements.

You would receive this message if the Create Invoice task has not run in the past 24 hours. It'll only disappear after a log entry has been recorded for the task successfully running. You can view [settings] -> [Company] -> [Automation] to see the last time it has run.

This is added in CORE-810 for v3.1 as a department-level override setting for the Support Manager plugin.

Duplicate of http://www.blesta.com/forums/index.php?/topic/1494-payment-due-notices-not-going-out/

Duplicate of http://www.blesta.com/forums/index.php?/topic/1494-payment-due-notices-not-going-out/

Duplicate of http://www.blesta.com/forums/index.php?/topic/1494-payment-due-notices-not-going-out/

Duplicate of http://www.blesta.com/forums/index.php?/topic/1494-payment-due-notices-not-going-out/

No, that is not possible. What are you trying to accomplish?

What error? Yes, we need as much information as possible to determine what issue you're experiencing and to try to duplicate it. Try Configure::errorReporting(-1);

See this thread.

We need more information as described in How to Report a Bug. Everything is working fine for me. So what do you mean the page "doesn't open"? Do tickets not appear? Do you get a 404 response? Are you assigned to the support departments for which that ticket is assigned, or are you assigned to that ticket explicitly?

Are you still experiencing this issue? Did it occur the first time you tried to install it, or did you previously have it installed, uninstalled it, and are trying to install it again? The query excerpt it shows starts with a question mark, as if PDO is not replacing them. But if that were the case, I'd expect you would have all kinds of problems. If you can check the logs for the full query that is executed, it may shed some more light on what's going on.

It already works this way. Services don't get provisioned until they are paid. So in your offline example, the service would be added as pending, with an invoice created that has not been paid, and so it will remain pending until the service is paid, or until you provision it manually. The login isn't shown because the password may not be known. The first time a client orders a service, an account is created for them in SolusVM, and that login info can be shown in the email that is sent. Any subsequent SolusVM services ordered by the client use the existing account information, but the service is now no longer aware of the password, and even if it were, there's no guarantee it would still be valid.

Then the additional request parameters are not available via $_GET. You can either use query parameters (e.g. ".../manage/5/?change=password"), or parse them out of $_SERVER.

You could try using a different version of MySQL to see if that may be the cause. But we haven't had any other reports of this problem that I'm aware of, so it seems like it would be a server issue.

What is the content of your welcome email template, both HTML and Text versions? Have you tried to remove their content just to see if an email will be sent, albeit blank?

Closing as not a bug.