Tyson

Users::login attempts to set a session cookie if you set $vars['remember_me'] to true, if the Session already contains an entry for "blesta_session_cookie" which is set to true, and the user does not require two factor authentication. Since you pass in the Session to that method, you can set your own cookie instead by calling it directly.

If you don't have cron tasks, then there is something wrong with your installation. You should check your database to ensure that the `cron_tasks` and `cron_task_runs` tables exists and contain several entries. If there are no entries, data has been lost/corrupt for some reason, and you will likely need to restore from a database backup.

A scheduled cancellation calls Services::cancel, and no event currently exists for that action. The event for Services::edit would not be triggered. This is similar to other service status changes mentioned in CORE-562. A couple automated actions could trigger the event for Services::edit, such as provisioning a pending service or creating renewing service invoices.

As shown in the docs, the first parameter must be an object of type Session, which represents the user's session. The Session is a component included with Blesta.

Look under [Tools] -> [Module Logs], and click on the table row for eNom to see the API logs. Using the sandbox requires different sandbox credentials than your live account. If you are using your live account credentials for both live and sandbox, then that would be why you received the error.

You may want to check that your invoice templates exist on the file system and that the template set for the company is correctly set to one of those. In Blesta, under [settings] -> [Company] -> [billing/Payment] -> [invoice Customization], the setting "Invoice Template" should be set to Default or Quickbooks. Try re-saving these values. These files should exist: /components/invoice_templates/default_invoice/ /components/invoice_templates/default_invoice/language/ /components/invoice_templates/default_invoice/language/en_us/ /components/invoice_templates/default_invoice/language/en_us/default_invoice.php /components/invoice_templates/default_invoice/default_invoice.php /components/invoice_templates/default_invoice/default_invoice_pdf.php /components/invoice_templates/quickbooks_invoice/ /components/invoice_templates/quickbooks_invoice/language/ /components/invoice_templates/quickbooks_invoice/language/en_us/ /components/invoice_templates/quickbooks_invoice/language/en_us/quickbooks_invoice.php /components/invoice_templates/quickbooks_invoice/quickbooks_invoice.php /components/invoice_templates/quickbooks_invoice/quickbooks_invoice_pdf.php /components/invoice_templates/invoice_template.php /components/invoice_templates/invoice_templates.php /components/invoice_templates/tcpdf_wrapper.php If everything looks good, then it would be helpful to know where and what action you performed in Blesta that led to this issue.

Is Plesk installed on the same server as Blesta? If so, this is due to Plesk restarting before responding to Blesta, and would not be a bug in Blesta. See this thread for more information on a work around.

That error occurs when the package quantity is too low, as Licensecart suggested. Either the quantity is in fact not set to unlimited, or the pricing is missing for the package such that the quantity could not be determined.

I'm not sure I understand the question. If you take a look at the API, the return values are listed for each method. e.g. Clients::create would return an object, of which the client ID is the "id" property of the resulting object. Clients:add simply returns the integer ID of the client.

You should take the return value from Accounts::addCc, along with the client ID, and add it as the debit account with Clients::addDebitAccount. You only do this once. Blesta will handle autodebiting it based on the client/company autodebit settings.

It would be helpful to see the code for the entire request rather than an excerpt of a variable. Most problems related to using the API tend to be incorrect usage of BlestaApi::post. Based on the error, it sounds like that custom field is required, but Blesta is not receiving any value for it.

I think what he's asking for is some context, i.e. where you see this behavior at in the interface.

Any objects you want to use in the view should be defined and set to the view. In your case, that would be YourModule::manageModule().

Blesta will still store the last four digits of a card number, and its expiration date for use in email templates (e.g. card expiration reminders). So you would still need to be PCI compliant. It sounds like what you want is to use a non-merchant gateway, as the client will be forwarded off-site to make a payment instead. This has been discussed at length in another thread.

Yes, modules are intended to perform service related actions, like registering a domain. However, they are not intended to be used to add other content (e.g. create packages and order forms), which is what I was referring to from the OP.

Open a ticket with us to request a dev license.

The order plugin wasn't updated in v3.3.2. That error appears to indicate that it is not properly referencing a service attached to the order. I would suspect this is data issue. The question is why doesn't the order have a service attached to it? Did you physically remove the service?

Modules are not intended to support that kind of behavior. You should create a plugin to do this instead.

I assume you mean 'module' rather than 'plugin', as they have very different meanings in Blesta. When a service is added, the module is checked for validation against the given domain name. This is where an error should be raised if the module determines the period is invalid for the domain's TLD rules.

After a domain is selected, the order form asks the user to fill out options set by the module related to the domain (e.g. nameservers). Then it moves on to selecting a package (if set), and continues just like any other order form of the same template. How does the order process influence your module? It shouldn't, as the order process is module-independent. The screenshots you posted illustrate the steps.

You're welcome. And I wouldn't necessarily say it's wrong, but there is an alternative, easier, way to query the database from Blesta.

Curious why you are trying to call PDO directly? If you're working from Blesta, you can use the Record component for queries.

What's in the logs? It sounds like the module does not attempt to provision, or has failed for some reason. Could be invalid data (error), or the invoice is unpaid (provision not attempted). The cron task for provisioning services should also be enabled, and not stalled. The number is the value of that field. The module makes all fields available to an email that it stores. They may not all be useful for display in an email, but could be for use in conditionals instead.

Blesta would either redirect the user to the client portal or display a 404 page when accessing an invalid resource, but there isn't any "Page Not Found" error as far as I recall.

What dates (created, renews, last renewed) are set on the service? The issue that Licensecart mentioned is related to displaying the date incorrectly on the invoice, which may be what you're experiencing. It could show an old date range. This will be fixed in the next version, but in the meantime, you could update the invoice line item to show the correct date.