Tyson

Attached to my post is an update to the Logicboxes module, v2.1.2. Backup and overwrite your old file at /components/modules/logicboxes/logicboxes.php. Then let me know if you continue to encounter any more errors. logicboxes.zip

PayPal invoice? I believe that's something PayPal controls. I'm not familiar with the particular section you're referring to or where PayPal derives the information it's displaying there. Perhaps a screenshot would give more insight?

Did you not setup a cron job on the server to run every 5 minutes? Your web hosting provider may have an interface you can access that makes it easy to setup a cron job.

This is normal behavior. The cron only runs tasks that are ready to be run based on their run time or interval. For example, if you run the cron right now, and then again in 1 minute, no cron tasks will actually run the second time because the minimum interval is 5 minutes and that time has not yet elapsed since the task was last run. Additionally, if the cron task has a null end date, it is considered to be still running, and the cron task cannot be run again while it is still running. In case it errors out or stalls (as in your case), it will automatically be stopped after 6 hours. However, since you are testing and debugging this cron task, it would be necessary to clear recent log entries from the database in order to run the task again. It's important to note, though, that deleting cron logs for some tasks may have detrimental effects, such as causing duplicate invoicing to be done for the same service. It sounds like there may be an issue with SwiftMailer working in CLI mode. Is there a different php.ini being used for CLI mode on the web server? A lower memory configuration may cause a memory allocation error at run time, which could lead to this issue. Taking a look at the php error logs would help. A log file should exist on the filesystem whether or not there are errors.

That may be something we can add then. CORE-1658

We haven't yet looked at what it would take to make some of those language definitions more multi-lingual-friendly. I think they were added without translation originally because they were proper names, but that may need to be revised.

Usually when a cron task fails it's because 1) there was a fatal error that stopped execution, 2) the task timed out, or 3) the task is still running and is taking quite long. If you haven't already, you may want to check the php logs for any errors that may have occurred during execution, such as running out of memory. You could also enable error reporting in Blesta, delete the cron task with a NULL end date, and run the cron manually from [settings] -> [system] -> [Automation] to see if any errors are encountered.

I see that not all expected fields are returned by Logicboxes. They may have updated their API to change the values it returns, or there may be permissions on your account blocking the data that is returned. In any case, what we can do is update the module to only display whois information for the contacts that Logicboxes responds with. In your example, you would have the Registrant Contact, but would not have any Admin Contact, Billing Contact, or Technical Contact. Although the module added these contacts when the service was created in Blesta, they don't appear to be available via the API for some reason. The same is likely true for the other "domsecret" error you received. This update would fix the errors you receive, but functionality may be more limited since, for instance, you cannot update some contacts from the Whois tab. I can look into fixing this this week and send you a private message with the update so you can test the fixes, since I do not experience this issue myself.

This will be fixed in v3.5.0

The end date is not currently editable in that way. The service end date is the date that it next renews, which are both the same day because they are both at the same moment. I can see from the display of the date range that it may not be clear due to the perceived overlap, but that is open to interpretation. You may encounter just as many customers that are confused about the other way of writing the date ranges. The interpretation may vary on context as well, e.g. "I work Monday - Friday" - Monday through Friday "I work 8:00 - 5:00" - I work 8 am to 5 pm. Instead of reading it as "From <date> through <date>", it may make more sense to read it as "From <date> to <date>", which is how the system interprets it. Would it make more sense if the date was written more explicitly to this point? e.g. as "(Jan 1 to Feb 1)" instead of "(Jan 1 - Feb 1)"?

It sounds like BitPay doesn't support refunds except when manually requested as mentioned here and here. Is there native refund support that can be accomplished automatically via the API that we're not aware of?

The register request looks good too. It seems like fetching the domain details results in an unexpected response, as if the expected fields are missing. Even if we fixed the error, the page wouldn't display any whois information because of it. I see that the domain details are not being logged (likely because it contains a lot of redundant data that may be re-accessed and re-logged frequently), I would suggest updating the module to add logging in so that we can see what the response is from Logicboxes. If you're able to update a file, find and backup /components/modules/logicboxes/logicboxes.php from your Blesta installation. Then open it and find this line: $response = $domains->details(array('order-id' => $fields->{'order-id'}, 'options' => array("RegistrantContactDetails", "AdminContactDetails", "TechContactDetails", "BillingContactDetails"))); Below that line, add: $this->processResponse($api, $response); Save the file and overwrite the one from your Blesta installation. Then go to the Whois tab for a service. Once you see the error, check the module logs again, and you should have an entry for domain/details. What does it contain?

The v3.5 beta should be available in the next few weeks or so.

That request looks fine, but it is also a different API request than would have led to the error. Instead of the URL shown as https://httpapi.com/api/customers/search.json, the request I'm looking for should begin with the URL https://httpapi.com/api/domains/details.json Do you have any logs for domains/details? Also, what version of Blesta and the Logicboxes module are you using? Blesta's version is shown in the admin footer, and the Logicboxes version is shown under [settings] -> [Modules] -> [installed].

The name of the gateway is stored in the database in the language it was installed in. It's currently not possible to display it in different languages.

You might be able to hide the optional fields in v3.5.0 using configurable options. There will be new settings to determine whether a config option can be added or updated by a client, but this is on a per config option basis, and is not apart of the Universal Module.

After you get that error, go to the module logs under [Tools] -> [Logs], click on the top row to see the Input/Output data from the whois/settings request. It seems like there is no response, or the data received from Logicboxes is unexpected. If you can include the log information, it may be helpful in seeing why you get that error and whether it is something we can work around. Feel free to redact any sensitive information.

Blesta keeps sessions active for 30 minutes. You may want to have the system remember you by checking the "Remember me" box when logging in. I don't like losing stuff I write either, which usually happens here on the forums. Sometimes the web browser stores the old post data, and going back can restore the information you wrote, but I made a habit of copying all of my content before hitting submit in case that happens.

Also, the coupon must be set to "Inclusive" so that it will only apply to all packages ordered at the same time. The coupon system will be changing (hopefully) soon, so this may be easier to manage later on.

After you've created the service, click the "Manage" link next to it on the client's profile page from the admin interface. Under "Actions" is a drop-down menu--select "Change Renew Date". A input box will appear with a calendar icon that allows you to change the renew date.

I'm thinking the issue may be with the check on whether the coupon recurs when it builds the coupon line item. I've created a task for us to look into it further: CORE-1652

This is a duplicate of another thread. Lets continue over there.

It sounds like you are submitting a form without a CSRF token as described in another thread. The question is then why is there no CSRF token for that form? That may be the case if it was explicitly disabled for the form, either in the code, or in your browser, or if you tried to submit the form from another website.

I haven't encountered this myself. Which version of Blesta are you using?

Take a look at the order form by editing it under [Packages] -> [Order Forms] and see if you have a checkbox checked for "Require Manual Review and Approval of All Orders". If so, all orders placed on the order form will not be created until you manually approve them for activation. To manually approve an order, you must have the Orders widget installed, which is available under [billing] -> [Overview]. If you do not see an Orders section when you go to that page, you need to add it to the page by clicking "Manage Widgets" on the left. A pop-up will appear. Drag the "Order System" box to the left side of the pop-up, then close it. The page will refresh and the Orders widget will appear on the page. A table listing will show all orders. A green check icon indicates the order was approved, and a red X icon indicates it has not been approved. To approve an order, click the checkbox next to the order in the table listing. At the bottom of the table, to the right, an option will appear called "Mark as:" which will allow you to mark the checked orders as a different status (Accepted, Fraud, or Canceled). Setting it to "Accepted" and clicking "Update Orders" will mark the checked order as approved. Once it is approved, the service will be provisioned automatically when 1) the invoice for that service is paid and 2) when the cron runs to provision paid pending services.