Tyson

Oh, I thought FiRaRi was referring to the format of the date/timestamp (i.e, format: "d M, Y g:i:s A" rather than "M j, Y g:i A") for reply dates, which can be updated in the config file from the Support Manager. I see now that you have a settings page in the Pro version where it can be updated from the admin interface. I don't think you're annoying. Quite the contrary, actually.

Did you happen to discover what the underlying problem was?

I think the Support Manager doesn't intend to use the default company localization date settings for the reply date because it chooses to display the reply date in a different format, as defined by the config setting in /support_manager/config/support_manager.php. At some point, I believe we were going to add a settings page for the Support Manager so you could change config settings like that from the admin interface. In the meantime, you can update the config file I mentioned above to set the date format.

Yes, something like what you've described could work. I'm not too concerned over the implementation strategy at the moment, though. Getting the design right is preferred, and then how best to implement that can be determined afterward. We'll have to think about this some more.

Adding support for tabs with suffixes for service statuses is too specific. The idea here is to create a more general solution that is flexible to all use cases regardless of specific (e.g. hosting) module platforms. I describe this more below.. I have given examples of cases where modules may want to display tabs for services of a specific status to accommodate its designed functionality. A specific example of an existing module does not need to be given, however, ignoring the possibility would be a hasty generalization. Whether additional effort needs to be added to modules to accommodate this behavior is determined by how flexible we decide such a solution to be implemented. For example, we could add a setting into Blesta that you can check to allow module tabs to be shown, or to hide them. Blesta would handle this independently of the module, and so no module would need to be updated to behave this way. If we wanted to be much more flexible to the module system, we could add support for a module method whereby the module verifies a tab's use. If a module supports three tabs, but only one should be displayed when the service is suspended, then Blesta can call a method on the module to ask it whether that given tab should be displayed/accessed, and pass in any variables (service, client, package, etc.) that the module may need to make that distinction. In this case, the modules would could be updated to include this behavior, or we could default the behavior to hiding all tabs anyway. The case may be rarely used, but it is nontheless valid. Not considering such cases would be restrictive to those that would use it otherwise. I agree many hosting providers use Blesta, however, the software is not tailored only, and very specifically, to hosting providers. The module system is not a hosting module system, but a general module system, and I think it's reasonable to generalize solutions to accommodate as many users/companies/industries as possible. The main point I'm making is that we shouldn't create a potentially restrictive solution (for some) to a problem when we can make it more open, flexible, and general purpose (for everyone).

Modules can display anything they'd like to display, and can choose to not show certain tabs based on service status if they like. Just because you're unable to think of a case where one might want to show tabs for suspended services does not mean there could not be one. I can imagine modules showing tabs for displaying alternate or advanced information particular to that module irrespective of service status. Perhaps they may even allow additional module actions to be performed by the client that are specific to suspended services, for instance, to allow the client to perform necessary pre-unsuspension updates to their service through the module prior to being able to unsuspend the service. This would no longer be possible if tabs are always removed for non-active services, and would prove to be a limitation of the module system in those cases.

The second log is OUTPUT, correct? If those are the only logs, then it looks like Blesta handles sending the client to BitPay, but BitPay is either not replying to Blesta, or that reply is lost somewhere along the way. I haven't looked at their latest API, but if they modified the return data sent to Blesta after a payment is made, it could be failing if Blesta can no longer interpret it in the same way. I would expect there to be an error if this were the case, which you may be able to find in your php error logs within an hour of the time the payment was made. Otherwise, you may want to take a look at BitPay and make sure there isn't some new configuration setting that may be refusing to send callbacks.

My guess is that the gateways you have set for the order form are not set to accept the currency you have set for the package pricing. What currency is the package being ordered in? Is that currency accepted by the Offline Payments and Stripe gateways as defined under [settings] -> [Company] -> [Payment Gateways]?

The class is defined in the "Blesta.pagination_client" settings you are using. You want to override those settings to set the class. e.g. // Overwrite default pagination settings $settings = array_merge(Configure::get("Blesta.pagination"), array( 'total_results' => $total_results, 'uri'=>$this->base_uri . "/[p]/", 'params'=>$params, 'navigation'=>array('surround' => array('attributes' => array('class' => "pagination pagination-sm"))) ) );

How do you have the options setup now? It sounds like you are looking for an easy way to say, "For the 3 month package term, discount all available package options -10%, and for the 6 month package term, discount all available package options -20%", etc. Unfortunately, that's not possible. The package options need to be well defined, and by that I mean they need to explicitly set a price at the same term and period as the package being ordered.

What is contained in the gateway logs? I think you should have log information similar to the following: Client goes to make a payment. Before redirecting them to BitPay, Blesta notifies BitPay of the payment and receives a reply (logged). Client makes a payment at BitPay. BitPay notifies Blesta within an hour regarding the payment (logged). Blesta asks BitPay to confirm the payment has been made, and gets a reply (logged). Blesta determines whether to accept the payment based on the response from BitPay, and a transaction is created. As long as BitPay's API is backward compatible, the gateway should still work this way.

The Universal Module uses the package name as the service name before the service is created when one is not otherwise set from service fields set on the product. This would be why you see the "Package Name - Service Name" displaying the same value on order forms. In most areas of Blesta, a service name (label) is expected, and it is probably best for you to create one for the service so admins and clients know what the service is for. That said, I'll remove the package name being used as the service name for services that have yet be created, as shown on the order form.

Thanks, this has been fixed for v3.4.1 in CORE-1565.

I'm going to close this as unable to duplicate. You can create a new report if you continue to encounter the error.

FYI, you might encounter this issue with the sandbox when using correct sandbox credentials in the case that your server and Enom's sandbox API server are unable to negotiate an SSL encryption algorithm to use for communication. I'm guessing the live and sandbox enom servers support different algorithms which accounts for the difference between being able to connect to the live server and not the sandbox.

I'm going to move this to feature requests. Category names/descriptions don't support multi-language by design.

Only one email is sent in regards to an invoice automatically on creation or renewal. This is irrespective of invoice type (i.e. proforma/invoice). It sounds like you want two emails to be sent, correct? The first after the proforma invoice is created, and one after the invoice is fully paid (and is no longer proforma)? If so, this would be better suited as a feature request, as that's not currently the intended functionality of invoice delivery.

Why/how would a client pay for an invoice if it doesn't exist yet?

The best way is to move the jumbotron outside of its current container, as Paul mentioned. However, if that's not doable, you could do absolute positioning, e.g. #myJumbotron { left:0; width:100%; position:absolute; } /* the div immediately after #myJumbotron */ div.container { margin-top:200px; }

The problem is more complex than updating that null value, which, by default, uses the language the system is currently using. If you only updated that value, it would be possible for clients to receive their invoice PDF in another client's default language. I've resolved this issue for v3.4.1 in CORE-1559. It will probably be available next week.

We have a task (CORE-141) to add support for SagePay, but it is not on the dev schedule at this time. I'm not sure if the UK version is different, but if not, it would be available with the release of that gateway. However, someone did integrate Omnipay into Blesta, which supports several gateways, including SagePay. You may want to check out that thread to see if it is a viable solution for you.

This appears to be an bug and will be fixed in v3.4.1.

The Universal Module sets the first service field value onto the invoice line item (after -), but it may be setting the value instead of the name. From your screenshot, the Business Legal Structure select option is where the problem lies. The Values set for that field contain "field1:Sole proprietorship", "field2:Corporation", etc. So the service has "field2" selected. However, I think it should display "Corporation" instead of "field2" according to your select option values. I'll make a note to look into this as a possible bug.

You can email sales to reissue the trial key since you changed directories. (@ blesta . com)

e.g. Loader::loadModels($this, array("Transactions")); $transaction = $this->Transactions->getByTransactionId($transaction_id, $client_id); if ($transaction) { // Transaction already exists }