Tyson

Do your Module Logs show any input/output related to the password reset request? A successful response indicates that the reset was performed on the server. Stats are always displayed, whether specific values exist for them or not. You can take a look at the SolusVM documentation for more specifics on the module, such as welcome email tags and the use of the VNC console.

We need to know steps to precisely duplicate this issue as described in How to Report a Bug, including your main service and addon services' settings.

Version of the Universal Module? Make sure it's upgraded to the latest version for that version of Blesta. Go to manage the Universal Module product you're trying to add a service for, and make sure its fields are correct, then re-save it, and try again.

There are a couple members on the forum that have made posts regarding MariaDB, and have it setup for Blesta with minor difficulty. They've run into a few issues that have since been resolved, but there could still be other issues with the system running on MariaDB vs MySQL. We can't provide much support for MariaDB users, though, as we have no test environment for it.

Yes and no. No, event listeners only receive and pass data, they do not render anything, like page content, so you cannot insert an intermediary step. However, yes, your event listener could redirect the user to some other URL, but then none of the other plugins that tie into that same event listener would ever execute. So it's best to never redirect from an event listener.

A mockup can be in any format. An image would provide a good visual, however.

Fixed in CORE-1012.

Thanks. Added CORE-1013 to fix this in v3.1.1.

Added CORE-1012 for this, v3.1.1.

In that case, you may want to remove the domain validation and check whether that resolves it. Update v1.2.0 of the module in /components/modules/interworx/interworx.php (line 1395) if ($edit) { to if ($edit || $package->meta->type == "reseller") { I haven't tested this change.

This is by design. Resellers don't setup a domain name since they sell domains to others. If your client is expecting to have a domain name, they either need to sign up for one separately, or use the "Standard" account type to create a siteworx account versus a reseller account.

Sounds like it could be one of the following: Interworx does not have any reseller packages set The reseller packages are not accessible via the API (permissions/API access issue) If you go to add a package, similar to your current package, do the Interworx packages load?

Blesta only logs serialized data, unlike what you've included in your first post, so the Inteworx API must have debug set to display such an error. I would need to see the actual input and output to try to see what's going on. So you can set Debugging to "none" for the Interworx module, then attempt to create a service. When you receive an error, check the Module Log and include all of the Input and Output details here. Feel free to redact any sensitive information.

And the error you described is displayed under the Module Log?

Could you provide some context to the errors you're receiving? I'm not sure where the problem is, nor what you were doing to receive it, etc., so it's difficult to determine the cause.

Just glanced at it and it looks like your AdminMain controller does not call preAction(). i.e. /** * Pre action */ public function preAction() { parent::preAction(); # # TODO: load other stuff, like models, helpers, language, etc. # }

Whether it is a mistake largely depends on the mail application used by those you've sent the email to. Most every mail app displays the HTML version of an email while the Text version is the backup, in case HTML cannot be rendered. I think it makes sense to have the HTML and Text versions of an email template as similar as possible.

It's unlikely we'll add a delete option in the interface that deletes all associated services along with a package since that can lead to several problems. Services are related to packages via their pricing. You'll need to join on `package_pricing` and `pricings` tables to determine which services belong to a given package.

In that case, you could use Blesta's search feature to search for the package by name, and that should return you a list of services that use them. The services attached to the package would need to be deleted first, and Blesta does not provide a way to delete a service (due to data integrity), unless the service is pending/in review. If a service exists of a different status (active, canceled, etc.), then you would have to physically remove the service from the database.

The email logs are template-independent. They only show the email as it was sent at the time it was sent. If you change an email template, the email logs don't change, but if you send an email with the updated email template, that email content will be shown in the log as written. The only thing that might appear off is the difference between HTML and text versions of the email. The email log will always show the text version of the email unless there is none, in which case it will convert the HTML version to text and show that instead. This is for display purposes only. Resending the email will still send it as it was written in HTML/text.

*.exe works for me. Are you sure the file isn't too large or blocked by the web server? Why not zip it up first?

What do you mean you 'flushed' the database? Obviously, if you have removed the client, pricing, package, or associated module data, a service could fail to add. If no errors exist, check your API credentials. You may also check the raw response from the request var_dump($response->raw());

Yes, include the realm in the username, like root@pam or root@pve. If you run into issues with modules, always check the Module Log for information on module requests and responses. They can give insight into what problem you're facing.

I assume you mean the date the service was created, in which case, no, you can't change this through the interface. No, there is no method of importing clients/subscriptions from Plesk and into Blesta. You would need to create each of the corresponding services in Plesk with clients in Blesta, and uncheck the "Use Module" box before provisioning the service.

When a client clicks the button to go to BitPay, the gateway first makes a remote request, and then redirects the client to BitPay. If the remote request fails, or the account credentials are invalid (probably what happened), then nothing would appear to happen. You may want to check your Gateway Logs for more info.