Tyson

We don't currently have an ETA on CORE-1593. It doesn't appear to be particularly difficult, but all of our attention is caught up in several other tasks right now, and will be for some time.

I don't believe the module supports ID protect. That may make a good feature request, though. Does it cost you money to enable the feature? Their documentation appears to indicate that there is a cost associated with using it. As for the Whois tab not loading, that may be caused by an error attempting to load the page. You may want to check the Module Logs under [Tools] -> [Logs] after attempting to load the page. If nothing appears out of place there, then check the php error logs on the server. If you're familiar with web browser dev tools, you could also check the network response from that action to see if any errors are occurring.

The cause of this issue is almost always the Root Web Directory setting in Blesta under [settings] -> [system] -> [General]. It should be set to the server's web directory as described in the docs. Double-check that it is set correctly.

I suspect this is likely the culprit. If you're using php5.5, you need to update your installation with the three files from the /hotfix-php5.5/ directory.

I don't understand the question. It would be best to open a thread under the Support forum and clarify the issue you're having by describing what doesn't appear to work, and the behavior you're experiencing because of it.

It may have been an issue with the currency you were using when testing the order form. I can imagine something like that happening if you have the currency setting "Use Package Pricing for New Services Only" checked, and your selected currency on the order is not available from any of the packages, so no packages can be displayed. For instance, this might happen if you test the order with one currency, then change the order form to not accept that currency. When you go back to the order form, your order form session data still uses the old currency that is no longer valid, and no packages can be loaded based on it. This only affects your session and not anyone else, but you can avoid it by fully completing an order before changing the order form and re-testing it.

I think the module needs to be updated to log this information so that you can check the API request/response. Without it, it's anyone's guess why it failed. FYI: The account limit is a soft limit in Blesta. It won't stop accounts from being created on the server, but if you have multiple servers setup, the module will prefer to add the service to the one that hasn't reached its limit.

There isn't a method by which to change the module row (server) of a specific service in Blesta. You could have a separate package in Blesta, and change them over to that other package which is on the other server. If all the service data is the same, and all that is changing is the server you have the account on, then you could update the module row associated with the service, but that would require an update to a record in the database. In Blesta, you can go to the module's configuration page under [settings] -> [Modules] -> [installed] -> [DirectAdmin] -> (manage). Hover over the "Edit" link for the server that you moved the account to, and your browser should show the URL. At the end of the URL is a number. That number is the module row ID. Make note of that number. Then head over to manage the service under the client's profile. Hover over the "Manage" link next to the service, and at the end of the URL is the service ID. Make note of that number. Then make a backup of your database. In the database, find that service ID from the `services` table, and update the `module_row_id` column of that record to the module row ID you noted earlier. After that you can head over to manage the service in Blesta to double-check it is able to communicate with the server. Take a look at the Whois tab, for example, which will query the server for contact information. If valid contact information is shown on the page, then it's working correctly.

Is her domain under your account now? The module attempts to either create the account (if it doesn't exist), or fetch the "order-id" (if it is under your LogicBoxes account) for Blesta. It sounds like neither can be done because the user's domain account does exist, but not under your LogicBoxes account.

I think some history needs to be saved in order to accurately list invoices and their earlier proforma number. As you mentioned, the current re-use of proforma numbers should be removed as well, otherwise duplicate proforma numbers could result, and it would further add to the confusion.

The DA module does sync with the DA server by fetching the actual number of users in the system. I just tested this myself to see that it increases when I add a service. I don't think the module logs this request, so any errors wouldn't be available in the module logs. It may need to be logged in order to check for errors in the DA response.

Since you want stats available for each version, I might revise it to: `applications` id, name, current_version, attr1, attr2, attr3, ..., attrn `versions` version_id, application_id, version, date, views, downloads `version_ratings` version_id, rating, count Depending on how your ratings will be setup, you might change that, but I was assuming something like a 5-star rating. So each version would have 5 records, one for each rating, and each time someone gave it that rating, you increment count on that record.

Serialized data isn't searchable. As mentioned, if you're unsure, create an ERD to get a better idea. Based on what you described, I would imagine something like: `applications` id, name, attr1, attr2, attr3, ..., attrn `application_versions` application_id, version, date `application_views` application_id, number_views, number_downloads `application_ratings` application_id, rating, count

No, it's because the proforma invoice and the normal invoice are the same record. This isn't currently possible without either creating separate records for proforma/normal invoices, or keeping history of just the old proforma number. But since the proforma numbers can be reused, searching by proforma number could yield multiple results.

I've created a task for us to look into this in CORE-1639.

Is it possible someone sent the invoice manually to the wrong person? If not, I would suspect a contact's email address may be the same for both of those clients, as Paul suggested.

I see. The invoice number changed when it was converted from proforma to a normal invoice, and the system doesn't keep history of the old proforma invoice information for reference in that table.

There is not currently a fix available for that issue. The coupon system was intended to be entirely refactored, so some functionality, like better proration support, was skipped for now. But some pressing features for v3.5 necessitate that we make some revisions to coupons now. Whether coupon proration will be apart of that, I'm not entirely sure yet. My suggestion would be to not use a coupon for a prorated service in the meantime, or manually update the invoice to set a discount instead.

Contacts::getNumbers

Could you clarify this point? I'm not sure which dates you are referring to.

I've updated the module to no longer use the activateSSLOrder method that GoGetSSL removed. This should resolve the error you're receiving regarding the "Unknown API method". I attached the updated module to this post, and you're welcome to test it to make sure it's working for you. Let me know if you encounter any other issues. You should backup everything within /components/modules/gogetssl/ from your Blesta installation, and then overwrite that directory and its contained files with the module files in the attached archive. gogetssl.zip

I think in order to see the thank-you message, you need to return a non-empty value from success. But the gateway should return the expected data as described in the method's comments in case it is used in the future for more than it is now. Glad you were able to get it done! And now that it is done, what do you think of the process in terms of the gateway's flexibility, its difficulty in creating, etc.? If you had to create another gateway, would it be as daunting?

I think what may be better for something like this is to have the ability to assign multiple client groups to a single custom field. Then if you move a client between client groups that have the same custom field, the existing value will be maintained.

Not beyond its inclusion for the payment received page that customers are redirected back to.

I'm not able to duplicate that behavior. If the invoice status is shown as "Unsent" in the interface, then it hasn't been delivered automatically. If you have checked the "Email" delivery option when you created the proforma invoice, it would have been queued for delivery via email and sent when the cron next ran. If it was then delivered successfully, the status would be shown as "Sent" in the admin interface. If the invoice is then paid and converted to a normal invoice, it would be requeued for delivery and emailed to the client when the cron runs next. Invoice delivery requeuing was added in v3.4.3 of Blesta. If the status continues to show "Unsent", then there may be an issue with the cron running the "Deliver Invoices" task, or the server may be failing to deliver email properly.