Tyson

The screenshot you posted appears to indicate that you are not running v3.3. I would expect to see the Wizard List and AJAX List order form templates if you were using v3.3. After you overwrote the files, did you remember to upgrade the installation? There was an issue with those images not appearing before, but that was resolved in v3.3 as apart of CORE-1406.

I suspect your email template still contains "http://{payment_url}". You can update the email template to change it secure http.

I'm going to close this thread as it has been discussed before. See here.

The reason you can't find the order number in Blesta's search is due to it being related to the Order plugin. The Order plugin doesn't provide search functionality (maybe it should), so you couldn't find it from there. However, you can find it in the order widget. Under [billing] -> [Overview], an Orders widget is available. If you don't already have that enabled, you should click to "Manage Widgets" and add it to your billing overview dashboard. It will list orders that are pending, accepted, etc., and will show the order number you're looking for, which is what the client sees on the confirmation page.

No, HTML isn't required. It's more of a 'nice addition'. But if your clients' mail applications don't support HTML, or you don't want to include an HTML version, then we shouldn't require that you set one that won't be used. The Text should be required because it is a fallback, and if you create a signature, you should have at least some text content for that signature.

A URL is just text, so it should be fine. But if you are creating an anchor tag around it, then you will need to escape any quotes, and make sure this language definition doesn't get filtered through Html::safe when it is referenced (not likely).

Have you verified the pay now tag in the email template is correct, and that the URL is correct in the email that was sent?

Your rule looks syntactically correct. However, php's filter_var function does not return boolean unless the filter fails. Since it usually returns a string, and all non-empty strings are evaluated boolean true, your rule wouldn't suffice for email validation. The Input component has its own email validation method. It was likely added after the documentation you referenced was created. Try: { "admin_email":{ "valid":{ "rule":"isEmail", "message":"Please enter a valid email address." } } }

A text version is always sent via email and is displayed for recipients whose mail applications don't, or can't, display HTML email. Blesta performs no conversion to copy the HTML over to Text. Because they are different mediums, most often you will want to tailor each email specifically as HTML or Text, and so content and placement will vary.

Can you provide some context to the code? Affected file? Why the original does not work, and why your fix resolves it?

Thanks for confirming it's working properly for you.

You should fetch the custom fields in the controller and make them available to the page you're referring to. You can fetch a custom field using Clients::getCustomField, and client custom field values using Clients::getCustomFieldValues, e.g. $client_id = 1; $custom_field_values = $this->Cliens->getCustomFieldValues($client_id);

When they cancel, do you not collect the amount due on the invoice? And why would the service be cheaper half way through the month? Since it's prorated, the amount due is relative to the amount of time between the service date and the pro rata day. If your pro rata day is the 1st, and they cancel on the 21st, it sounds like you would actually keep 10 days worth of free cash by not providing the service from the 21st to the 1st.

I think what they mean by 'not possible' is that it is currently not an available behavior in Blesta. And the code that handles this happens to be in an encoded file. But if you're familiar with jquery, you can take a look at /app/views/client/bootstrap/javascript/jquery-client-3.2.0.js, and update blestaLoadWidgets to update the interface to display the widgets in your custom order.

Have you made any custom code changes to Blesta that might affect this? Or other changes, perhaps, to restrict access to certain routes? Do you experience the same issue using a different web browser? Since you mentioned you have all of the correct privileges, it may not be Blesta that is generating the 403 Forbidden error. Have you checked your web server logs for more details? Do you have mod_security enabled, with a rule configured that could be causing the web server to deny access to that URL?

I'll close this thread, as you provided more information in a separate thread.

Hi Ashley, Which page (URL) in Blesta were you looking at when you received those 403 responses as shown in the screenshot? Typically, a 403 Forbidden response is caused by either Not being logged into Blesta to view a particular resource Not having authorized access to a particular resource I assume you're logged in, so if it is #2, then you should check your Staff Group permissions. You can find these under [settings] -> [system] -> [staff] -> [staff Groups] -> (edit). When you edit the staff group you're in, be sure to check that the checkboxes under the Packages section are checked. You can re-save the settings to confirm. If you still experience the same issue, you can try enabling all of the staff group permissions, and check again to see if you still receive that 403 error. And if so, let me know what page you were looking at, and I'll see if anything else may be causing it. The "/billing/admin/packages/moduleoptions/" URL is valid in Blesta if you have Blesta installed under a /billing/ directory. Unless you made changes to the routes for Blesta in the config file (/config/routes.php), or made custom modifications to the .htaccess, I don't think this would be related to the problem.

FYI, this issue was resolved in CORE-1455 for v3.3.1.

FYI, this issue was fixed in CORE-1465 for v3.3.1.

This issue is resolved in CORE-1390 for v3.3.2.

Hah! The issue sounds like it may be the bug described in CORE-1390 where the service renew dates shown in the invoice line item description are incorrect after service renewals. The old renew dates were shown rather than the new renew dates, so it would appear the dates were a month older than they actually are. Licensecart, does this sound like the issue you described?

Fixed in CORE-1487

Do you purge your cron task logs often? My guess is no, so the date passed to Services::getAllRenewablePaid should be within the last interval for that cron task (last 5 minutes?), so it should only fetch services that were paid (invoice was closed) since that time. You can debug to see if the date is correct. But if you are still receiving that service as a paid renewable service, then it must be an active service with a line item on an invoice that was closed within that interval, otherwise there is something else going on that should be debugged. Have you made any custom changes that might be related to this?

Something like the following may work (untested): { "hostname":{ "valid":{ "rule":"isEmpty", "negate":true, "message":"Hostname must not be empty" } }, "configoptions[client_id]":{ "valid":{ "rule":["matches","/^[0-9]{4}$/"], "message":"Please enter a four digit number for the referring client." } } } You will need to change the name of the config option ("configoptions[client_id]") field to the one that you created.

The SolusVM module hasn't changed since v3.2.1. If your SolusVM fields do not load for an old package, it may be that that old package is no longer referencing a valid module row (server). i.e. if you updated the service's package to change the "SolusVM Master Server" to something different, or that server is no longer valid. There could also be a separate error being generated that is causing the fields to not load. You could take a look at the web server logs for more information on any errors. Or you can enable error reporting in Blesta, and if you're familiar with developer tools in your web browser, you can check the AJAX requests on that page to view the response for when those fields were requested, which likely contains more information on the error. To enable error reporting, which will allow errors to appear in the interface, you can update /config/blesta.php and change Configure::errorReporting(0); to Configure::errorReporting(-1); ...and change it back when you're done.