Tyson

When is the invoice due? Based on your screenshots, it looks like the service should be suspended 5 days after an invoice has passed its due date. And since your service was added on Dec 1 and suspended on Dec 6, I would think that the invoice was created Dec 1 and set to be due on Dec 1 as well. If that's the case, then this would be expected behavior.

The knowledge base has already been completed for v3.4. If any tweaks need to be made to it, that will happen during beta. Additional features, like interfasys mentioned, would come in another version.

Has the invoice associated with that service been paid? Based on your Billing/Payment company settings for Invoice and Charge options, services are suspended some number of days after the invoice is past due.

Modules can set groups for module rows for easier management. If you have 10 servers to provision services on, then you can group them all together in the module so that they can be in one group on the package. That will let you have the option of moving, upgrading/downgrading services between those servers. Depending on the module, you could also set limits on the number of accounts so that when one server is 'full', another one can be chosen when the service is created.

Check your Interworx package welcome email, and/or the service creation email template. Look at all tags you have set, and any conditionals for both HTML and Text versions. Each tag should be in braces, {tag_here}, and you shouldn't have any special characters like asterisks. Conditionals used should be closed with the appropriate {% endif %} tag, or {% endfor %} for loops.

If you just upgraded Blesta, make sure you run /admin/upgrade in your browser. If you already ran the upgrade, then enable error reporting in your config file (/config/blesta.php) by setting... Configure::errorReporting(-1); ...toward the top of the file. If there are errors causing the page not to load, then you should be able to see what they are afterward. It would be useful to know what errors are being generated.

The invoice isn't delivered after it's created, rather it is queued for delivery and later delivered when the cron runs. While you can't stop the invoice from being queued for delivery, you can instead remove it from the queue. After the invoice is created, you can fetch each of the delivery methods that were created from Invoices::getDelivery, and then delete each one via Invoices::deleteDelivery.

I don't think your solution is something we'd be able to use. It's generally bad design to override existing fields (i.e. non-merchant gateways) to inject special-case alternate functionality (i.e. credits). I'd also be curious to know how your solution affects the Wizard and Standard templates considering they already handle credits.

If you go to a client's profile and email yourself a copy of an invoice manually, is the image available? I wonder if GD is not configured/available via CLI on your web server.

Yes, clients can't add services using multiple currencies to the cart. Currency calculations operate on one currency, so they have to clear their cart or add a separate order to purchase services in a different currency.

One of the following would likely be true: The client doesn't have any custom field values The API call or credentials are invalid The API call causes a fatal error or exception in the application The API call never gets executed

What is the response? null? That method always returns an array. If the array is empty, then I suspect the client does not have any values set for any of the available custom fields. Perhaps the custom fields were created after the client already existed?

It sounds like the Order plugin would have to support and listen to its own custom events in the case you described. Plugins supporting their own events would be interesting, but I think the OP's feature could be resolved simply by updating the Order plugin to support the 'one service per client' feature. As Licensecart mentioned, this does bring up some potential issues, such as when the service is cancelled, can they order the service again? What if an admin manually adds multiple services to the client? Would this negatively affect you, the client, or the services in some way? And how would this affect addons? Could addons be ordered multiple times if they are added onto separate services? Some things to think about..

The invoice and service(s) are shown for each order in the Orders widget on the Billing Overview page.

How important is it to know that someone is viewing a page in Blesta at any given time? The user logs get updated (date_updated) when someone loads a page, which is sufficient if you don't need to check idle time, such as a user reading a page for a prolonged period of time. But even then, they could have the page open in their browser, but be away from their computer or doing something else.

Table data doesn't disappear automatically, especially for cron tasks. Something is awry with your installation. If you have use the Blesta API, or use any 3rd-party plugins/modules/gateways, its possible any of those could have deleted database records. Otherwise, I would suspect that data was deleted manually, and there may be other data removed that you're not aware of yet.

The translator doesn't yet support the ability to translate definitions from specific areas (e.g. client UI, admin UI, modules, gateways, plugins, etc.). You could post your translations to the forums for others to use, but there is no way to include your file translations into the translator.

Is this the entirety of your validation? If so, that is not sufficient, and the reason you're able to continue on to the next page is because no validation occurs. You have defined a rule in $rules, but never use it for Input validation, e.g. public function validateService($package, $vars=null) { $rules = array( ... ); $this->Input->setRules($rules); return $this->Input->validates($vars); }

You could take a look at session information, or a combination of that and the logs, but you won't be able to determine who is currently viewing the site at any given point in time based on only that information. Session info can remain until it expires, and users that are remembered in Blesta can close their browser rather than logout, and they will still be seen as "connected" even if they may no longer be viewing the site.

Yes, the password is expected to be given in plain text.

Method calls from plugins don't function like the API SDK. What I mean is that you do not pass in an array of key/value pairs representing the parameters and their values. Instead, you pass in the parameters directly. i.e. $field_id = 3; $client_id = 352; $value = 1111; $this->Clients->setCustomField($field_id, $client_id, $value);

The welcome email only has access to service fields that are saved. So if you want to send those other two fields, they need to be saved for the service. If they are not service-specific, you could set them on the package or module instead, if that would make sense for you to do.

You'll need to provide more details on what you're trying to do. It sounds like you're working with a domain module, but you may not have setup your validation rules correctly.

I think this would depend on the type of service you're selling. You can set quantity for config options already, but there are several cases where it would not make sense for a customer to choose a quantity for a service, such as a domain. e.g. a quantity of 2 identical domains with the same options wouldn't make much sense

Fetch the users from the user logs and determine whether they are staff/clients. See the System Overview plugin for an example of how it does this itself.