Tyson

The gateway used for a payment depends on the currency of the invoice being paid and the currency you have enabled for your merchant gateway. For example, if Authorize.net is set for USD, and you are paying a USD invoice, then Authorize.net will process the credit card payment. The system doesn't display the name of the merchant gateway that is used to process a credit card payment (e.g. Authorize.net or BluePay). This is irrelevant to the customer--they just want to make a payment with their credit card. Who says they know what Authorize.net or BluePay are, and what the difference is between them?

A message is already displayed in the client/accounts/ page if autodebit is disabled: "Automatic payments have been specifically disabled for this account, please contact a staff member to reactivate. You may select a payment account as your default, but it will not be charged automatically until it has been reactivated by staff." Not showing navigation links on specific conditions unrelated to permissions is more complicated, so we wouldn't go that route at this time. However, I've added CORE-1834 to v3.6.0-b2 that removes the section from the client UI sidebar if the payment types are disabled and the client has no payment accounts.

The .htaccess file included with Blesta already contains a rule to force HTTPS, which is commented out by default. Simply remove the # symbol at the beginning of these lines # Force HTTPS #RewriteCond %{HTTPS} !=on #RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=307,NE,L] i.e. # Force HTTPS RewriteCond %{HTTPS} !=on RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=307,NE,L]

Disabling access to suspended/canceled service module tabs is in v3.6.0-b2.

The SSL Store and Go Get SSL modules ask for several fields: first/last name, address, city, state, zip, country, state, etc. -- wouldn't it make sense to simply use the contact's information in lieu of these fields?

This is fixed for 3.6.0-b2.

That would work.

Glad you were able to find it in the docs. Upgrading is also described in the README file that comes with Blesta. To reiterate for anyone else--after uploading your files to your Blesta installation, go to your Blesta installation in your browser at /admin/upgrade/, and follow the steps shown on that page (essentially, click a button).

Thanks for the find! CORE-1833

It's not known who scheduled the service to be canceled, so it currently cannot be determined whether a client should be able to remove a service's scheduled cancellation.

This would be better encapsulated in the module itself, as Blesta is unaware of specific module fields and their intended display. You could add the fields into the template you mentioned by hard-coding them, but they will only apply to the Universal Module--not any other modules. The template contains a $service object, which contains an array of module fields ($service->fields). You can take this data and display it however you like. I would suggest first adding print_r($service) to the template so you can see what fields you're working with. Also, don't use $this->Html->_(...) in conditionals unless you intend to check the HTML encoded value, although I see no reason you would want to. You should only use it for display purposes. By default, HTML::_ displays content. You must pass a second parameter, boolean true, in order to return it instead.

The screenshot you included indicates the error is with the tags you are using in the portal. i.e. you have a {% if .... %} tag but no subsequent {% endif %} tag that follows it. It's important to ensure the tag syntax is valid.

You could alternatively use vQmod (search the forums for it) to change language definitions, without them being overwritten on Blesta updates.

I think this is because you're being redirected twice. Try changing the redirect URI to the login page itself then. $this->requireLogin($this->client_uri . "login");

Per LicenseCart's video, the invoice being paid is a non-recurring invoice. Being non-recurring, the subscription button for PayPal is not shown. This is because the recurring invoice has not yet been generated, and it would not be generated until Oct 27, 2015. If LicenseCart had gone back to the Invoices table in Blesta, under the "Recurring" section, he would have seen the "Count" of recurring invoices was "0", indicating no recurring invoice had yet been generated. The invoice that was initially created is a one-time invoice. You can set it's bill date and due date since it's a normal invoice. There is no expectation that the bill date you set for the initial invoice must coincide with the term and next renew date of the recurring invoice. You could easily make the bill date of the invoice today, and set the recurring invoice next renew date tomorrow, with 1 month recurrences. This would mean the initial invoice is for 1 day and the recurrence is for 1 month. If it were possible to pay this using a PayPal subscription, it would be possible to receive payment for an invoice that does not yet exist. While I don't think this is a bug, it may be an improvement to make it clearer that the invoice you're creating initially is a one-time invoice. Perhaps, also, there could be a way to not create an initial invoice altogether.

So $1.33 for the first month (prorated). You want to override it from $10 to $5 for the second month (first full month after proration). Then set a price override of $5 and uncheck the Prorate checkbox. It says $-0.67 because it is attempting to override the first month (prorated), which is the $1.33. Halving the $10 to $5 also halves the prorated price from $1.33 to $0.67 and will create a credit for this amount (if you have it configured to do so) when the Prorate checkbox is checked. I'm not sure what part you consider to be a bug. Could you clarify?

You can't create a package without a module (whatever kind, Universal or otherwise). That checkbox will not be checked if you had unchecked it. Going back in your browser will re-check it because it is checked by default and is probably missing your previous POST data to uncheck it again. "Provision using the __ module" means that Blesta will attempt to call the module to provision the service. With most modules, this means a remote call will be made to an offsite location to provision the service. For example, if you were using the cPanel module, and you checked that field, Blesta would have communicated with cPanel to create a new cPanel account and to add the domain to it. However, if you do not check that field, then the cPanel API will not be contacted. Instead, the service will only exist locally in your Blesta installation and will not be tied to anything offsite. The Universal Module does not interface with an API. Instead, it can send notifications (if you set them up on your product). Unchecking the 'provision' field will simply not send the notifications you had setup. In short, the module is your product. The package is your configuration/pricing of the product. And the service is an individual instance of the package. Without a module, you have not defined anything to sell. This would be analogous to creating an invoice with a blank line item. Do you mean the package welcome email? What do you find confusing? The package welcome email is injected into your Service Creation email template when a service is created, which lets you set specific details about the service for the customer.

Are the automation tasks still enabled under [settings] -> [Automation]?

I think naja7host brought this up to me, but I haven't had a chance to look into it yet. But if it's an issue, it should be fixed sometime this week. Blesta includes what erroneous data? State and country ISO information?

As naja7host mentioned, you can redirect to the client URI for clients not logged in with $this->requireLogin($this->client_uri); If you want to show a message, you should set a flash message before that redirect $this->flashMessage('notice', "You must be logged in to use the order system.", null, false); $this->requireLogin($this->client_uri); If you don't want the "Order" box to appear on the portal page, you can update the portal to remove the HTML that displays it from within Blesta under [settings] -> [Plugins] -> Portal (Manage link).

Closing this thread as CORE-1734 and CORE-1735 were both resolved in v3.5.1.

Going to close this thread as not a bug per my above post. Create another thread if you feel there is indeed a separate bug with this calculation.

Since this issue was resolved when the OP upgraded to a newer version of Blesta, I'm going to close this thread as not a bug.

You can follow this issue in CORE-1821.

Going to close this as not a bug. But you can create feature request threads to improve on these aspects if you'd like.