Tyson

We have a task for this @ CORE-768. No ETA yet.

The braces used by styles and JavaScript (i.e. { and }), conflict with the H2o parser for tag replacement in email templates. The parser expects variables to be between the braces, e.g., {service.name}, but since you have CSS styles defined, you have { padding-top: 0 !important; ... }, which is invalid H2o tag syntax. You can either use inline-styles instead, or you can update your config file in /config/blesta.php to change the characters used by the H2o parser to something else, like two braces. The latter requires every area in Blesta that defines variables parseable by H2o (e.g. the portal, all email templates, package welcome email templates, the universal module, etc.) to be updated to use the new characters you define. I also notice that you are defining a lot of base HTML tags, like the body and head tags. I presume this is a "full-page template", but the WYSIWYG does not support this by default. The WYSIWYG will strip your html, head, and body tags. To keep them, you would need to update the ckeditor configuration. i.e. Update /vendors/ckeditor/config.js and find at the bottom of the file: config.entities = false; And add below it: config.fullPage = true;

You're probably setting an error message with AppController::setMessage or AppController::flashMessage without setting the $in_current_view paramater to false.

The system automatically redirects users to login to the last page they were previously on when they were logged out, as a matter of convenience. So if you were logged in as an admin, and you also went to a client profile and clicked to "Login as Client", you would be in the client interface. If at this point you were to logout, the last page you were on was in the client interface, and upon logging in again, you would be redirected to that page. I found it kind of annoying myself to login to the admin interface and be redirected to the client interface in these cases, so I changed it in CORE-2166 for v4 to no longer redirect to an alternate private interface. It's still possible to be redirected to the public interface on login, though, if that was where you had logged out previously. i.e. This won't happen anymore: But this can still happen:

Did you receive the same notice about Mailparse not being installed when you installed Blesta? phpinfo is a function that outputs the PHP configuration settings. Blesta doesn't parse this to determine whether you have Mailparse installed. Instead, it checks whether the Mailparse extension is loaded. The extension_loaded function may require phpinfo--I'm not sure. If you're disabling certain functions in php.ini, you'll have to be aware of this fact and its impact when installing or upgrading software on the server, as any new software can try to make use of something you have disabled.

See my reply in your other thread.

Are you using xCache? If so, try disabling it. A couple other threads (here and here) report an identical issue when using xCache.

CORE-1686 is a bit different. I don't see a conflict in credits/voiding here, so allowing for both options to be enabled at once should be acceptable. There are roughly 3 or 4 major tasks left to complete before v4 beta. I would expect the beta to start this month, and the official release after that will depend on user feedback, issues/changes, etc.

You could add the invoice line item descriptions to your client's dashboard if you wanted to, yes. You can loop over the invoice line items and display the description on the page. It would require you update the file /app/views/client/bootstrap/client_invoices.pdt, or /app/views/client/bootstrap/client_invoices_applied.pdt if you wanted it to appear in the expandable section.

Are you referring to the root web directory setting? The value you set for it depends on your web server configuration, so Blesta wouldn't be able to tell whether the path you set is correct for this purpose. Rather, it could only say whether the directory specified exists, which is not particularly useful. The directory set on installation would exist, but may not be correct because of the web server configuration, which is out of Blesta's scope to determine. A preview of links generated wouldn't be possible through the interface. The purpose of the Root Web Directory setting is to resolve the path in CLI mode, which you are not using when viewing the settings page. In order to view a preview, an email would have to be queued and sent by cron, which contained sample link(s). If you were to receive such an email and discovered the links were incorrect, the correct solution may or may not be to update the Root Web Directory setting, depending on the web server's configuration. Yes, some people do have issues with getting the cron to send emails with the correct links, and I can understand the frustration. We can only partially ease that frustration with a feature like I mentioned above. The main culprit for issues with the Root Web Directory tends to be the web server configuration.

I see. A feature for a prorated credit on the remaining service term upon cancellation would have to be added. This wouldn't be tied to the existing service downgrade credit. I created CORE-2200 for this feature and detailed what I think will need to be done to make it happen. If you were to do it yourself in a way you intend to share, it may be best to do it on version 4.0 of Blesta since essentially every file has changed.

Did the installation complete successfully? Do you have tables in the database? Was a Blesta configuration file created? (you can find it under /config/blesta.php) If the Blesta configuration file was created, does it contain the database information you entered during installation? e.g., at the top of the config file: Configure::set("Blesta.database_info", array( 'driver' => "mysql", 'host' => "localhost", //'port' => "8889", 'database' => "MYDATABASE", 'user' => "MYUSERNAME", 'pass' => "MYPASSWORD", 'persistent' => false, 'charset_query' => "SET NAMES 'utf8'", 'options' => array() ) );

Why do you expect a credit to be issued for the canceled service? A service cancellation is a removal of the service. A service downgrade would be a change to the term, period, renew date, or service options that result in a prorated price change whose total is less than zero. Depending on your changes, it's possible to receive a credit larger than the total amount of the initial invoice for the service's original term and period. Consider a client orders a service: - 1 month, $5.00 (30 days in length) - You update the service to change the renew date to a day later (service is 31 days in length). - You update the service to change the renew date again to the day after the creation date (service is 0 to 1 day in length, depending on time of day). Prorating this change would prorate 31 days for a service whose term and period equates to 30 days, resulting in a credit of [(31 days * $5.00) / 30 days] = $5.1667 ($5.17). This may not be the best API request to make as it both cancels the service and changes the renew date. The renew date change is prorated, and the service is immediately canceled. As I mentioned above, a service cancellation is not a downgrade, so there is nothing to prorate. No service data has changed, so there is nothing to prorate.

Yes, this was already fixed for v4.0 in CORE-1898.

It sure takes up a lot of the page, though.

Neither currently support setting a default option. A Select field, though, has to start with displaying an option, so the first item in the list is the de facto default option.

Those values look indicative of a Universal Module product rather than a package option. You may want to place them in a Select field instead, which defaults the first option to selected.

Services:add Invoices::createFromServices

Is the upgrade a queued service change? If so, when you edit the service, you should see a message at the top of the page that reads, "This service has pending changes. Updating this service to upgrade or downgrade any of its values will cause the current pending changes to be canceled." What you can do in this case is scroll down to the "Upgrade/Downgrade" section. Uncheck the "Prorate" and "Use Module" options, and click to save the changes. This will result in the queued service change being canceled (no new queued service change will be created), and the associated invoice will be voided automatically.

What is the exact error? Have you tried using a different browser?

It would be useful to have some context on when and where you want to check a user's logged-in status. The posts above assume you're doing it from a controller that extends AppController.

Is that error message from your web browser or from the module? What's contained in the module logs under [Tools] for that add service attempt?

No, I mean when the transaction was created, i.e., when a record was created in Blesta for receipt of payment by the customer. In most cases, the invoice associated with the payment would have been created sometime earlier. It would appear in the tax liability report. The date you filter by for the tax liability report refers to the date the invoice was closed, meaning that 100% of the invoice total must be paid within that date range. The transaction reports are a bit different, as the filter dates refer to the date the payment was received. The date the payment was received is not necessarily the same date that invoices are closed. It's possible to make a payment a year ago, but only have that amount applied to an invoice today. In this case, the invoice would appear in the tax liability report for today while the transaction reports would have included it a year ago.

What does that mean? Blesta suspends a cPanel service by telling cPanel to suspend the account based on its username. So the username you have set in Blesta for the service should match whatever cPanel account username it should refer to.

The tax liability report will only include data for taxable invoice line items belonging to closed invoices, where matching tax rules still exist and the invoice was closed between the given dates. The transaction reports will include all transactions received/applied, where the transaction was created between the given dates. So, if you have paid invoices with line items that are not taxable, or partially-paid invoices, or you have deleted tax rules, or transactions were created before your start date, but applied to invoices after the start date, then the tax liability report total would appear less than transactions'.