Tyson

What star? Are you referring to the sub navigation in the admin interface? That's not a bread crumb, but rather a set of sub navigation links. You set those in your plugin through plugin actions (i.e. the nav_secondary_staff action). If you indeed want bread crumbs, I would suggest taking a look at how the Support Manager knowledgebase builds its bread crumb links.

I often find reading text to be a poor medium for communication. As 70% of communication is miscommunication, the lack of non-verbals, tone of voice, and propensity to read between the lines, the likelihood for miscommunication only increases and it can be easy to misinterpret the meaning of words to come to an alternate, and unfortunately mistaken, conclusion. I believe that is the case here, as I am not placing blame or fault on anyone. I am merely trying to gather information and offer possible solutions along with my reasoning behind them. You mentioned: I just tested the email template on a new Blesta installation, but sadly, was unable to experience this issue myself. If it is indeed an issue with the default template, we would like to fix it immediately. That said, I have not had anyone else come forward yet with the same problem, so I only have your information to work from. I wish you the best of luck with your new system.

What Licensecart described can work, by allowing you to re-run the upgrade script. However, there have been other database changes since that version, so you could end up encountering more SQL errors (e.g. attempting to add fields that already exist). What is the SQL error you encountered when running the upgrade? If you're not able to resolve the SQL issue, you may need to manually perform the database upgrades on your installation. i.e., look at the upgrade scripts from /components/upgrades/tasks/ and apply them manually to your database. Make sure to make a backup.

While I agree it would be easier to wipe/cancel the associated services when an order is marked as fraud, doing so may not always be ideal. For example, the order system can automatically mark an order as fraud, and it could do so incorrectly (false positive). In this case it would require manual intervention by an admin to determine its legitimacy, which is why the service is currently marked "In Review"--so you can cancel it yourself or activate it instead.

I illustrated in your other thread how you can do it. (Please create only one thread for this topic) It is probably best for your gateway to create it's own order number for the purpose of passing it to the API.

I think it's first important to understand the payment flow here. When a payment is made using a non-merchant gateway, the gateway is unaware of how the invoice it is intending to pay is created, or even if there is an invoice at all. You can make a payment using the non-merchant gateway to pay for nothing. In your case, however, you want to pay for an invoice created from an order in the order system using the Order plugin. This is a special case, and should be treated as such. Which means, you should not rely on this to always be true, and must setup logic to handle the cases where it is not. In your non-merchant gateway's class, you should have defined a buildProcess method. This method accepts, optionally, an array of invoice amounts as its third parameter. In that array is a list of IDs representing the invoices being paid. If you are paying an invoice on the order form, you should only have one invoice ID in the list. You need to take this invoice ID and find the associated order ID from the order system. Considering the order system is a plugin, it may not be installed for the company. You should check that it is first. Loader::loadModels($this, array("PluginManager")); $order_number = "N/A"; // Is the Order plugin installed? if ($this->PluginManager->isInstalled("order", Configure::get("Blesta.company_id"))) { ... } The Order plugin associates an invoice with the order, so you must find the correct order that matches the invoice ID you were given. However, the Order plugin does not provide a method to find an order by invoice, so you must write your own. First, make sure you have an invoice number. $invoice_id = null; if (isset($invoice_amounts[0])) { $invoice_id = $invoice_amounts[0]['id']; } Now you need to find the order number associated with the invoice. Since the Order plugin does not have a method for doing this, you can either 1) add a method for it to do it from the OrderOrders model by updating the source code yourself, or use the Record component to query the database for it manually. The later is more difficult as you will need to manually connect to the database by passing valid credentials yourself. See here for an example of someone that has. I will skip that part and simply assume the Record component is setup to perform a query. Loader::loadComponents($this, array("Record")); # # TODO: create a connection to the database # try { $order = $this->Record->select()->from("order_orders") ->where("invoice_id", "=", $invoice_id)->fetch(); if ($order) { $order_number = $order->order_number; } } catch (Exception $e) { // Unable to fetch the order number } Putting it all together now: Loader::loadModels($this, array("PluginManager")); Loader::loadComponents($this, array("Record")); $order_number = "N/A"; // Is the Order plugin installed? if ($this->PluginManager->isInstalled("order", Configure::get("Blesta.company_id"))) { // Do we have one invioce? $invoice_id = null; if (isset($invoice_amounts[0]) && count($invoice_amounts) === 1) { $invoice_id = $invoice_amounts[0]['id']; # # TODO: create a connection to the database so we can run a query # // Can we fetch an order for this invoice? try { $order = $this->Record->select()->from("order_orders") ->where("invoice_id", "=", $invoice_id)->fetch(); if ($order) { $order_number = $order->order_number; } } catch (Exception $e) { // Unable to fetch the order number } } } // Use the $order_number

The services were placed in In Review status. Marking an order as Fraud will: Set the order to Fraud status Set the client to Fraud status Set the service to In Review status Void the associated invoice Only setting the order to 'canceled' will cause the service to be canceled as well.

What version did you upgrade from? That table you're missing was added in v3.5.0-b2. As Licensecart mentioned, make sure you follow the upgrade process completely, and run ~/admin/upgrade in your browser. Afterward, your installation should be working properly. Also, always backup your installation before an upgrade.

It does sound like Blesta was either unable to create the config file during installation, or the data you entered during installation could not be written to it. Do you have /config/blesta.php? Or just /config/blesta-new.php? /config/blesta.php contains your database information. This should have automatically been added during installation, but you can set your database information directly into that file.

We'd like to revise the domain management system before integrating more domain modules, otherwise they will just have to be replaced.

Haven't experienced an issue like that myself, but generally, it can be caused by a timeout from the server after performing the action. Can you duplicate that behavior? Can I create an account to try to duplicate that behavior on your install (is it a test environment)? Based on your form details, I would expect you to receive an error regarding an invalid email address.

As nelsa pointed out, copying/pasting HTML into the WYSIWYG editor is not satisfactory because it can produce alternative HTML, different from what you've pasted, which may create invalid tag syntax. For instance, it might enter a paragraph inside a tag and produce something like "{%<p> if invoice.status == 'active' %}</p>". This is not visible except when viewing the Source, so it is always best to make direct HTML changes while in Source mode. I presumed the OP's issue was experienced with default templates, but I'm more convinced this is the cause instead.

I use it in my own system without issue, but I customized my use of vQmod, so I can't attest to problems with others'.

Changing the address shouldn't affect whether it leads to an error. Did you look over the Service Creation email template as well as the Package Welcome Email template(s) from which the pending services would be created? Do they contain any invalid tags/syntax issues? What would be best is to see the exact error that is caused when the cron is running those tasks. You should first enable PHP error_reporting by updating your config file (/config/blesta.php). At the top, there should be this line: Configure::errorReporting(0); Change it to: Configure::errorReporting(-1); Since those two failed tasks currently have a NULL `end_date`, you can physically delete those, and ONLY those, records from the `log_cron` table. What you should then do is run the cron manually from [settings] -> [system] -> [Automation] immediately, before the automatic cron tries to run them again. By running it manually, any errors that are encountered will be displayed in your browser. Updating those email templates does not save? What is the error? The conditional syntax, i.e. if..else, must follow the correct format and end with a concluding endif. The concluding endif is what most people seem to overlook when making changes. See Customizing Emails. e.g. {% if invoice.status == 'active' %} This invoice is active. {% else %} This invoice is not active. {% endif %}

As Licensecart mentioned, the Payment Received email template is a receipt of payment, but does not include any invoice(s) as attachments, if any were paid with it, partially or otherwise. The only reason I can think that the amount applied appeared as twice the value you entered is if you had paid it twice. For example, perhaps as you were recording a payment, that invoice was paid via cron from a loose $100 credit, or the client happened to make a payment at the same time for the same amount you were recording. In any case, it's best to look at the Transactions table to see where the payment originated.

At what point do you want to get the order number? And from where? What do you plan to do with the order number? We don't yet understand what you're trying to do so we're not sure how to answer your question. We could use more information. For example, you can fetch an order by it's order ID (assuming you have it) by calling the OrderOrders model of the Order plugin from within your controller: $this->uses(array("Order.OrderOrders")); $order_id = "15"; $order = $this->OrderOrders->get($order_id); if ($order) { $order_number = $order->order_number; }

Upgrading from v3.3.0 to v3.6.0 (currently beta) requires you to upgrade with all 3.6.0 files--there is no 'patch' available for upgrading minor versions. The first step is to backup all of your current files and the database before attempting to upgrade. If you have a set of Turkish language setup in Blesta, such as from the Translator, they should be defined in their own tr_tr directories. These files don't get overwritten because Blesta only comes with en_us. The only reason your language would have been overwritten is if you defined your Turkish translations in the default en_us files.

You're right, the behavior you're experiencing doesn't make sense. Did you check both the "HTML" and "Text" versions of the email template? Are you using multiple languages in your installation, or just English, US? Are you sure the "Scheduled Payment Reminder" email template is the one causing the issue? This template is only sent, at most, once a day to specific clients that have an open invoice and a payment account set for autodebit--and then, it is only sent X number of days before the invoice is automatically set to be autodebited as defined in your payment due notice settings. All of these criteria can make it difficult to consistently test whether this is the offending template. I would try to run the query to check the cron log again: SELECT * FROM `log_cron` WHERE `run_id` !=0 AND `end_date` IS NULL ORDER BY `start_date` DESC LIMIT 0,30; Or try using a database tool (e.g. phpmyadmin) to check the `log_cron` table for tasks whose `end_date` column contains NULL.

Sounds good. I'll close this feature request something we wouldn't do by default.

The domain availability check in your screenshot doesn't have any TLDs set. Normally, you would enter "mydomain" in the input field and select the TLDs you want to check as checkboxes (which would appear below it), e.g. ".com", ".net", etc. On your package, everything in the "Module Options" section is set by the module--in your example, Enom. Then your module should define a addService method to handle this registration. Blesta will call this method on your module when a service is being added with it. Your module should take this information, validate it, and create the domain with your registrar via its API, and return the expected data back to Blesta. What personal data? What "Handle"? When the service is canceled in Blesta, Blesta will call your module to cancel the service via the cancelService method. Your module should perform any action necessary with this information (e.g. mark the domains as "to delete" at your provider). Your module can define service management tabs where you can display any information, accept post requests for changes, etc. Tell Blesta what tabs you have created by defining them in getClientTabs and getAdminTabs (for the client and admin interfaces, respectively). When an admin or client goes to manage the service, they will have access to those tabs.

We don't show company address in the structure. I guess this is a custom change you've added? If so, then running it through nl2br wherever you're using it is the preferred solution. We wouldn't update the company address field to automatically display line breaks as HTML breaks otherwise.

Where is this shown?

The query LicenseCart linked to doesn't contain a LIMIT clause. Make sure you run the query exactly as it's written. When you receive a parse error when editing an email template, the template doesn't save until you resolve the error. If, for some reason, that parse error still exists in that email template, you will need to fix it. Edit the email template under [settings] -> [Emails]. A parse error occurs when you have entered invalid tag syntax--i.e. everything between an open and close brace: {}. The error you encountered suggests you have an invalid ampersand set. You said that you edited the "Auto Debit Pending" email template when you received the parse error, but the cron task for "Provision Paid Pending Services" is failing. That cron task does not send that email template, so I am more inclined to believe that you have a problem with one of these email templates instead: Service Creation (or the package welcome email set for one of the package's that attempted to get provisioned) Suspension Error Unsuspension Error Creation Error Cancellation Error

Take a look at the module documentation to see how to integrate into Blesta.

Update this file: /app/views/client/bootstrap/client_accounts_cc_info.pdt