Tyson

Thanks for clarifying. I think the issue has to do with a pro forma invoice being paid (and converted to an invoice) before it is sent, which ends up removing it from the list of invoices to deliver. I'll take a look at fixing this as apart of CORE-1465.

A 'counter' doesn't technically exist, but is rather generated on the fly based on the other settings.

Pro forma invoices can still be sent. It sounds like the OP doesn't want any type of invoices sent unless they're paid, so disabling the unpaid email template should suffice.

Content is escaped when displayed, so the label attribute in the config would not be the place to include HTML. Instead, you could create a new attribute to include your custom link and language, then update the module where that field is rendered to check for those attributes and generate the HTML manually. In this case, you wouldn't be able to use ModuleFields, unless you left the label as plain-text, and set javascript that updated the plain-text to a link when the page is displayed. e.g. Configure::set("domain_fields.nl",array( 'Term' => array( 'label' => Language::_("domain.Terms",true), 'type' => "checkbox", 'options' => array( 'Yes' => Language::_("domain.RegistryTerms",true) ), 'custom_label_link' => "http://domain.com/", 'custom_label_name' => Language::_("domain.terms", true) ) ); Then look for 'custom_label_link'/'custom_label_name' in your module, and make adjustments accordingly. While not identical, the Namecheap module does something similar in order to include tooltips. You can take a look at that module for reference.

Yes, 36 hour days would be great! The most up-to-date documentation in (almost) every software project is the source code itself, so there will always be more that needs to be done on the rest of the documentation. But I agree, they need more attention.

You don't send customers copies of unpaid invoices? Why not disable the Invoice Delivery (Unpaid) email template so that unpaid invoices are not sent?

Based on his description and the screenshots, it looks like FiRaRi is using the 3rd-party Support Manager Pro. We're not able to help with 3rd party plugin issues, but perhaps PauloV (whom created the plugin) could respond, or you can contact him directly.

We would need more information to diagnose your issue as described in How to Report a Bug. I don't experience this issue, as the cron delivers pro forma invoices as expected, but you did not specify the version of Blesta you are using. If you're using one of the v3.3.0-b* (betas), then you should upgrade to the release version. You should also take a look at your invoice delivery settings and cron tasks to ensure they are all enabled, and that your cron is running regularly without issue. Blesta does not deliver invoices set to be delivered via "paper", because you need to manually print them from the print queue.

What you're experiencing is normal behavior for invoice number generation. The first invoice ever created begins at the invoice start number, and every number generated afterward is incremented by the invoice increment value. So changing the start value after invoices have already been generated continues to create invoice numbers starting at the next incremented value. As you've discovered, if you want to change the start value in the future, you need to consider that the next invoice number is generated from the increment value and set the start value accordingly. If it did not increment when you changed the start value, it would be possible to generate duplicate invoice numbers, which is arguably a worse outcome.

I think you need to be more specific as to what you're trying to do and how and where it applies in Blesta. Some simple HTML markup to accomplish what you're asking would be: <label> <input type="checkbox" name="tos" value="true" /> I agree to <a href="#">Terms & Conditions</a> </label>

For the A/R reports, make sure your staff group has the Aging Invoices Report Email BCC Notice checked under [settings] -> [system] -> [staff] -> [staff Groups] -> (edit). This will make it available for staff to subscribe to it. Once that is saved, go to [My Info] -> [Notices] and check Aging Invoices Report to subscribe to that email. You may want to also verify that the Deliver Reports task is enabled under [settings] -> [Company] -> [Automation]. Tickets are handled by the Support Manager plugin, so you should make sure that your staff user under [support] -> [staff] -> (edit) is set to receive ticket emails, and that you're both assigned to the departments you want to receive emails from, and your schedule is set appropriately. Ticket emails will only be sent to you during your schedule. And lastly, you can double-check that the email templates are enabled and that they are allowing attachments to be sent (particularly for the reports), under [settings] -> [Company] -> [Emails].

From a security stand-point, obfuscating the URI to a public-facing interface is inconsequential. There is no gain to be had from security through obscurity.

Which page are you referring to exactly? e.g. [Client Profile Page] -> [Add Service (under Actions)] -> [select Package] -> [select Term/Status; Module Fields] ? If you have module fields on that page that are not being validated when you click "Continue", then it sounds like you have not added those validations to YourModule::validateService.

I believe those tags (e.g. {module.*}) are from the Universal Module as apart of a package Welcome email. The Welcome email does not know what fields you have created for a product, and so it cannot display any of the actual fields. The asterisk (*) in the tag denotes "all", meaning that you can use any of the fields you created for the Universal Module product. The tag (e.g. {module.*}) should not be used as written, because the asterisk does not represent a usable tag. There's more in the documentation for the Universal Module, but you can also take a look at an example here.

You can validate multiple fields in one rule through a callback method that accepts each value as a separate parameter.

I created CORE-1456 so we can take a look into this issue.

Thanks for the info. Is that setup fee apart of a service or a configurable option? I'm only able to duplicate this behavior with config options. Added to CORE-1455

Can you provide an example? What are the URLs?

The order form you created does not use the template you edited, which is why the changes don't appear. I believe the template you want to update is /home/my_blesta_dir/public_html/plugins/order/views/templates/standard/types/registration/signup.pdt

The sandbox field is meant to use the test URL, as it currently does, however some APIs like Logicboxes require a different set of "demo" credentials when performing actions in test mode. We can add a tooltip next to the sandbox field to indicate your demo account credentials should be used, but I don't think we want to remove the field entirely. The documentation states that demo accounts should still use the test URL, so you should still check the sandbox field when using your demo account credentials.

Could you provide a working example that adds a setup fee for a service when it renews? (i.e. the service settings, package settings, etc.) Are you sure an addon wasn't added to the service? Addons are separate services, and any setup fees on the addon will be charged for when they are created, even if the addon is attached to a service that already exists.

Pro rata has nothing to do with free trials. It is for setting service dates to renew on a specific day each month, for simplicity.

Where are you changing the font size? It should change if you've updated the file and then went to view an invoice.

Transactions::getCredits

Could you explain what you were doing when you received that message?