Tyson

Do your configurable options have prices set in GBP for the 1 month term?

Clear your browser's cache, or if in the admin area, clear the navigation cache by going to edit your staff group, and simply click to save the settings.

Check the gateway logs under [Tools] -> [Logs] for a response from the gateway. There could be an error or no response from PayPal, which ends up not marking the invoice paid. Also, if you're running Blesta on a machine (like your personal computer) that is not accessible from the Internet, PayPal can't send Blesta a response.

Stripe also needs to be set to accept the currency that the service is using, and that currency needs to be checked on the order form.

Service options are shown to the client when ordering a service. They can pick and choose what they want from those options. Package options are typically used to let only admins choose options of a product to make available in a package. Rodrigo's work-around is a 3rd-party change, and is not included in Blesta. You would need to edit and overwrite files as he described in that thread, and maintain them through updates from Blesta.

CORE-171 Unknown ETA.

I would avoid inserting directly into the database. Blesta performs rule validation and error checking to ensure the data conforms to expected formats, which may not be apparent in the database schema. This may lead to issues with some information not displaying, or being used properly, if you bypass those checks.

Changing the renew date to a day further in the future shouldn't send an invoice. I don't see how it would be possible for a new invoice to be created after you moved the renew date forward. Can you consistently replicate this behavior? If so, please let me know what dates and settings you're using to do so.

You may want to check the client's Mail Log (under Actions), to see if the email was sent. It may have been sent, but just ended up in your spam folder. Also, when adding the service, make sure it's checked to send the order confirmation email. Currently, the service information page does not show fields available from the module. That may be a good feature request, although someone may have already created a feature request for it. Important module-related service information, like the IP address, or login credentials, are usually shown when clicking on the service row. In fact, many tables in Blesta act this way. What do you mean by not forcing the use of the hostname TLD? Blesta and the SolusVM API always use the hostname together with the associated TLD. If you're looking to trim the TLD off of the hostname in the email template, that wouldn't be possible. There is no filter for truncating content that would accomplish that.

Yes, I believe the hostname you enter when you installed Blesta is used in the from address for email templates. I'm not sure I'd classify this as a bug, but it may be nice to have that stripped out if possible.

Yes, this has to do with your use of the "clients" subdirectory, which interferes with the route "client" used by Blesta.

The {package.*} tag is not a usable tag (neither is {module.*} or {service.*}), and is only shown to suggest that you can use anything. The asterisk is a common term to denote "all". The tags that are actually available depend on your Universal Module product. Take a look at the Universal Module documentation. In particular, the package fields for a product. In that image, there is a Label (Data Center) and a Name (dc). The value in the "Name" field is the tag. Since this is a package field, the proper use of that tag in the Welcome Email is {package.dc}. Similarly for the service fields--proper tags would be {service.hostname}, {service.ns1}, etc. So just replace the asterisk with the name of the field you created for the product.

The IP address should be shown in the Welcome Email when using the {service.solusvm_main_ip_address} tag. Here's a list of all available tags. In Blesta, you can view this IP address as a client, or an admin, from the client dashboard page, under the list of services. Click the table row for that service and the Primary IP will be shown. Is this what you're looking for?

Depending on what you change the renew date to, what your Invoice Days Before Renewal setting is, and whether you invoice suspended services, Blesta can create an additional invoice. This is because, essentially, you changed the renew date such that system determines an invoice should be created. And this is by design. The cron can renew services multiple times to 'catch up' to what it may have missed--and this may be what you are causing by changing the renew date back, and now Blesta thinks it 'missed' renewing the service. Consider an example: If a service renews on a daily basis, starting from Jan. 1, 2013, then a new invoice should be created every day. If you disable the cron from running, for instance, it will not be able to renew those services, and no invoices will be created. If you then enable the cron on Jan. 1, 2014, the cron will start where it left off by creating 365 invoices for that service and finally changing the renew date to Jan. 2, 2014. If you think the system behaves differently than this, then please create a duplicable test case and send me the details so I can replicate it. Information on the service (term, date created, date renews), both before and after the service renews would be useful.

The cron logs don't adhere to the Clean Up Logs setting, since removing cron logs too frequently can lead to several issues. Instead, cron logs are purged based on the cron log retention policy set in the Blesta config, defaulting to 10 days. Looking at it again, I don't think this would be due to the logs. However, if the cron created a duplicate invoice for the service, then I would expect it to have bumped the renew date as well, and it looks like it didn't do that a second time.

PauloV, were you able to duplicate this issue? Blesta creates invoices based on the renew date and days before renewal settings. Based on your screenshot, it looks like the second invoice was created two days after the first. This could be if you did one of the following between the time the first and second invoices were created: You changed the service's renew date to a date closer to the current date, or in the past You've deleted cron logs, in particular the Create Invoice cron log responsible for the first invoice being created We would need steps to duplicate this issue if we were to deem it a bug. Anything you have in terms of your company/client group settings, whether you've changed them, whether you've edited the service, invoice, etc., would all be useful information.

I don't see a way to go about adding that feature without modifying core code or using vQmod, as you mentioned. I think we'll need to discuss that idea more internally.

Indeed, the ClientPay::method() is not a supported event. Here's a list of supported events.

The PayPal sandbox is working fine for us regarding refunds. I wonder if PayPal is treating the sandbox/live accounts differently.

What part of it is not working for you?

There should be a cron log that at least says the task Provision Paid Pending Services task was attempted. If a request was made to the module, it should be in the module log. Does the service have an order-id attached to it? When you go to manage the service and view a tab, like the Nameservers tab, does it say something like "This information is not yet available"? If so, then there is no order-id set for that service, and it can't perform any remote requests. The order-id should have been automatically determined when the service was originally created.

The error states it failed due to an internal error where PayPal timed out processing the request. How long did it take PayPal to respond to the request?

If you continue to have this issue while running v3.2.1, it would be helpful to know which page(s) you see the error message, and how your order form is configured (e.g. template type).

The service renew date is bumped because an invoice was created for it. Whether a client pays for the invoice determines whether the service remains active, such as by how you have Blesta configured to suspend services. These are defined in the Invoice & Charge Options under [settings] -> [Company] -> [billing/Payment]. For example, if you have a service that renews every 7 days, and you have the Invoice Days Before Renewal set to 10, then an invoice will be created 10 days in advance (3 days before the new service term is set to begin). If you then set the Suspend Services Days After Due to 3 days, the client would have to pay for the service before, or on, the day that the service is set to begin, or it will be suspended.

I don't think that would solve the issue, since it would only use daemon ID's you explicitly set, while the problem appears to be how a daemon ID is chosen when not explicitly defined. Based on how I think I understand the Multicraft logs, I think WHMCS is sending an update to change the daemon ID. The first command was to create the server, which it added automatically to daemon 1: 2014/06/30 12:49:42 [info] [application] [User 18, 64.90.52.151] Sending command "server 178:refresh" to daemon 1 2014/06/30 12:49:42 [info] [application] [User 18, 64.90.52.151] API: Created model Server, 178 Then a second API command was sent from WHMCS to update the server to change the daemon ID to 2: 2014/06/30 12:49:42 [info] [application] [User 18, 64.90.52.151] API: Updating model Server, 178 2014/06/30 12:49:42 [info] [application] [User 18, 64.90.52.151] Sending command "server 178:refresh" to daemon 2 2014/06/30 12:49:42 [info] [application] [User 18, 64.90.52.151] Sending command "server 178:refresh" to daemon 1 This leads me to believe that it auto-provisioned it on daemon ID 1 anyway, but that WHMCS changed it to daemon ID 2 afterward. How/why it changed the daemon is the question. Do you know if you defined daemon ID(s) in WHMCS for it to create the server on?