Tyson

I agree that it appears to be a JavaScript issue. I can only replicate your dashboard page when JavaScript is disabled in the browser. Make sure you have it enabled.

The documentation is not out-dated. The success method is called when the client returns back to Blesta. No validation is necessary here. The validation occurs via the gateway callback.

Can you clarify how you imagine this would work? For example, when you say a ticket should be opened to anyone listed on the account, does that mean only that contact is made aware of the ticket, or that that contact is the only one to receive an email notice regarding the ticket, or...?

The example you quoted from the docs only shows a simple example of how to create an email template. You may want to handle this in your plugin's install and uninstall methods so you can create the group and template when your plugin is installed rather than when accessing a controller, as the example illustrates. You can take a look at the Support Manager plugin source for working examples. Set a name and description for the email template by defining a language file, admin_company_emails, containing them, in the following format: File: /plugins/myplugin/language/en_us/admin_company_emails.php Contents: <?php $lang['AdminCompanyEmails.templates.action_name'] = "Email Template Name"; $lang['AdminCompanyEmails.templates.action_desc'] = "Email Template Description"; The "action" in the language term AdminCompanyEmails.templates.action_name should be the action of the email template group you created. For example, your group action is called MyPlugin.custom_action, so the language term would be $lang['AdminCompanyEmails.templates.MyPlugin.custom_action_name'] = "Email Template Name";

The return URL is the URL the client gets returned to when they come back from the non-merchant gateway's website. The callback URL is where the gateway will respond to the payment to notify Blesta that a payment has been received. If the gateway does not support both of these URLs, then use the callback URL to do both.

A ticket has to be opened with the client, but any of the client's contacts can respond to it so long as they have permission to access the support system.

With this in the module: public function getAdminServiceInfo($service, $package) { return "hi"; } Yes, I see "hi" when I click on a service table row on the client's page in the admin UI. That is where you are looking for it, correct?

You don't need to reinstall the module. Returning a string is fine, and in fact, what you've described displays under the service row in the admin interface for me.

You're not able to save the meta data for the gateway because the acceptable_payment_type is in an invalid format (i.e. an array). The system does not automatically serialize array data for storage with gateway meta like it does for modules, so you will need to serialize and unserialize it yourself. $rules = array( 'acceptable_payment_type' => array( 'valid' => array( 'rule' => true, 'message' => "Payment type invalid", 'post_format' => array("serialize") ) ) );

Mike? I think you mean Cody?

This issue is resolved in v3.6.1.

When you added the check payment, did you set a "Date Received"? That field sets the payment date, so if it happened to have been set for tomorrow, it would account for the discrepancy in the revenue statistic. By default, the date received is set to today. Next time you record a payment, you might check the Date Received to make sure it shows the current date by default.

From which package was the service created? Check the welcome email set for that package and ensure it contains content in the HTML tab. If you are using multiple languages in Blesta, make sure that the package welcome email and service creation email have defined content for the HTML tab in each language.

If the revenue you entered appears a little later in the day or the next day, then it sounds like the timezone is off a bit. Does the timezone you have set under [settings] -> [General] accurately reflect your current timezone? The statistics will use this timezone when searching for revenue to display in that widget.

A few things: The method "get_states" should be "getStates" If you're using CSRF tokens (enabled by default), you must pass the CSRF token in the POST request as well, or the request will be denied. I don't see any reason you can't use a GET request instead. The error is in regards to setting a message via setMessage or flashMessage. If you are calling either of these methods, you should pass additional parameters to these methods that indicate the message view is not from your plugin, but from Blesta core instead. You might take a look at the admin_clients_add.pdt template for an example of fetching states, and use the blestaRequest function for your request instead.

The cause for the missing config options is as Licensecart mentioned--because of the currencies. You can set 1 month term EUR pricing on the config options, or uncheck the setting "Use Package Pricing for New Services Only" so the system can perform currency conversion instead. Everything that is ordered has to be in the same currency.

Does it not appear for the revenue this month/year statistics as well, or just today?

Are you using xCache? If so, try disabling it. A couple other threads (here and here) report an identical issue when using xCache.

I don't experience this issue. Are you sure you are viewing the billing overview statistics for the currency that the invoice was paid in?

Yes, that is how passing parameters works. If you want to specify a third parameter, for instance, you must also explicitly pass the first and second parameters, regardless of whether they are optional.

First parameter to Form::create is the URI to POST to, default null for current page. Second parameter is an array of attributes--this is where you can set your class. e.g. $this->Form->create(null, array('class' => "class1 class2 class3"));

See CORE-1866

That's a broad question. I would suggest getting more familiar with how pagination is created from existing sources and debugging your attempts to get what you have working. See this sample, for instance.

This is the reason the cron task is stalled: Error: Undefined property: stdClass::$precision #0 /home/*******/domains/billing.*******.co.nz/public_html/app/models/invoices.php(1255): UnknownException::setErrorHandler(8, 'Undefined prope...', '/home/*******/d...', 1255, Array) In v3.5.1, currencies were updated to include precision. The only reason you would not have currency precision when using Blesta v3.5.1+ is if the upgrade was not run. After you upload all of the files for a newer version of Blesta, you must make sure you run ~/admin/upgrade/ in your browser and follow the steps to upgrade (basically just click a button). After you run the upgrade, head over to [settings] -> [Currencies] -> [Active Currencies]. All currencies should have a precision set (i.e. number of digits after the decimal place). You may need to update NZD (and other currencies) to their expected currency precision.

Yes, the "widget_staff_billing" action only allows a widget to appear in the staff billing section. If you want a subnavigation link under the Billing tab, then you want to use the "nav_secondary_staff" action.