Tyson

The sandbox has different requirements for nameservers (they must be explicitly set in your sandbox account) to be accepted. Since the previous fix from CORE-1456 was able to resolve this for you, I'll close this thread as already fixed.

If I understand that correctly, that function simply checks whether a transaction exists given the transaction ID from the gateway. You could perform a similar check by calling Transactions::getByTransactionId(). However, I don't think that is necessary, as Blesta already does this and simply updates the existing transaction if you had received multiple responses from the gateway for the same transaction.

The problem with using an arbitrary password score in Blesta is that each password field would need to define its own requirements and its own algorithm for calculating scores since the passwords Blesta accepts range from Blesta account passwords to cPanel account passwords and more, and each system has different requirements. For example, if cPanel only allows up to 12 character passwords, and Blesta only allows 13+ characters to be scored at 100, it gives the false impression that there is more to be gained. Personally, I don't think a password score is necessary. I think it would be more beneficial to show whether the password conforms to its given password requirements, and then the requirements can be set to whatever you would determine a score of 100 to be.

Split and Quote are when replying to a ticket. Either split specific replies into a separate ticket, or quote replies in the current ticket for your reply. The merge, as shown in Licensecart's screenshot, is on the ticket listing page, where you merge entire tickets (all replies within them) with each other. Are you suggesting that after you perform a merge, the ticket that replies have been merged into have an entry stating the old ticket #? Similar to how the old ticket gets closed with the message "This ticket has been merged into ticket #2695697."? In the future (CORE-1120), we plan to make that message a log entry rather than a System reply. I think your message would be best as a log message instead of a reply.

Attributing a "score" to passwords would be arbitrary, unless you have specific requirements that dictate how such a score could be constructed? Passwords may need to conform to different guidelines depending on where it is used and what it helps to protect. I wouldn't want someone to think that an arbritrary score of "100" somehow makes a password secure.

Can you clarify whether you encounter this issue if you login as the client (NOT when an admin) and attempt to view an invoice? Do you only encounter this issue with invoices sent in emails? Which email template did you experience this with? Even though you have the client set to use a separate language by default, did you define language for the invoice type you're viewing (/components/invoice_templates/default_invoice/language/ab_cd/default_invoice.php)?

I would really like to have that password generator sooner rather than later.

I'm not quite sure I understand then. When you receive the callback from the gateway, you want to subsequently send a "success" message back to the gateway?

You can take a look at other non merchant gateways included with Blesta for working examples of this functionality. However, here is a basic example: Instantiate the Http object so you may POST to the gateway POST to the gateway Handle the response e.g. something like the following: public function validate(array $get, array $post) { // Instantiate the Http object if (!isset($this->Http)) { Loader::loadComponents($this, array("Net"); $this->Http = $this->Net->create("Http"); } // Log the response we received initially $url = "https://domain.com/"; $this->log($url, serialize($post), "output", true); // Log that we are about to make a request $post_data = array(/* set any data to pass along */); $this->log($url, serialize($post_data), "input", true); // Post to the gateway $response = $this->Http->post($url, http_build_query($post_data)); // Log the response from the gateway $this->log($url, serialize($response), "output", true); // Handle the response if ($response == "success") // do something else // do something else return array( // ... set return key/value pairs ); }

Have you taken a look at this thread? If you're running the Admin Tools plugin from naja7host, that appears to be causing the problem.

There are no logs regarding PayPal? Usually this means that either PayPal did not attempt to notify Blesta that a payment was made, or is using the wrong URL to do so. Licensecart's link details how to set the correct URL.

Are you using any third-party extensions that may be preventing the action? Is there an error displayed?

What would Blesta be billing for? Are there open invoices, or services that should be renewing for that client?

The fields shown when managing a service should be defined by the module in Module::getAdminAddFields.

How would that work? If you had a value of 1 and a client mistyped their CC number when submitting a payment, they're going to be frustrated that they can't fix it and pay. Then they might fail to pay an invoice on time, say it's not their fault because the system didn't let them pay... and chaos may ensue afterward. Seems like it could be a hassle for legitimate customers.

Yeah, by seed, I mean the key used to setup the token.

Alternatively, you could make note of the seed information and save that in a safe location.

I think most APIs have their own reference ID, and most modules simply store and use that ID where necessary. I don't think you need to go out of your way to match them to service IDs in Blesta. That ID should be a back-end ID anyway, which no one would see (except admins, if you allowed them to add an existing TCAdmin account into Blesta without provisioning it).

That's interesting. It's not something I would personally use because I frown upon backdoors, but some may find it useful.

Perhaps the SolusVM module should be updated not to show the option to change the password for KVM virtualizations.

Do you have a link to their documentation (hopefully available in English)?

The root web directory should be an absolute path, as tenaki mentioned. If you encounter this issue with emails sent via cron, but not when sending an invoice email to yourself manually, then the issue is most certainly the root web directory path.

As you guessed, the service ID is not available to Module::addService because it is unknown until after that method call, and would only be created if no errors were encountered. What are you trying to use it for? You might be able to create a plugin that checks the addService event handler, and use that to determine the service ID after the service has been created.

I don't think a task exists for custom client fields on invoices. You can update the invoice PDF directly under /components/invoice_delivery/default_invoice/default_invoice_pdf.php. You would need to add the appropriate logic for fetching client custom fields and replacing content.

I'm not sure I understand the request completely. What error do you receive when trying to uninstall a plugin? Are you actually uninstalling it, or disabling it?