Paul

Remove everything after pipe.php, and make sure the path to PHP is correct. cPanel will likely do several things: 1. Add the correct hashbang to the top of pipe.php 2. Make the file executable (chmod 755) 3. Strip off the path to PHP at the beginning of the forwarder Next, time for testing. Don't worry about missing folders, they are parameters and do not correlate to the file system.

Did you look here? https://docs.blesta.com/display/user/Support+Manager#SupportManager-email-pipingEmailPiping Actually setting up piping on your server can vary from server to server. We give an example of doing this manually on a server with no control panel. If you have a control panel, you'll likely set up piping through it instead.

ACL Permissions are access permissions. They are group-based. Go to Settings > System > Staff > Staff Groups, edit the group. You'll see a list of all ACL permissions, make sure that you have permission to what you need. When you install a new plugin, usually your group is granted permissions to the plugin. However, if you have multiple groups, you may need to grant permissions to others who need access. By default, for security purposes, access is not automatically granted to all staff groups.

We aren't going to convert file based templates to database based templates.

If you modify a file in Blesta, then upgrade Blesta by uploading the files over your existing install, then yes, it would be overwritten. This is why I suggest creating a NEW CSS overrides file. This way, all you have to do is add back your include in structure.pdt which would take all of 1 minute.

So an option when editing an Addon Package Group, to only allow it to be added to an existing service? Meaning, you could not buy it during order form checkout, but only after the parent service has been provisioned?

It's likely there will be an option to add custom CSS or JS via the UI, near "Settings > Company > Look and Feel" in the future, but it's not a high priority right now.

In an ideal world, it would be great if everything was open and audited with our seal of approval. Because Blesta is extensible, 3rd-party developers can create their own extensions. Those extensions are therefor their own intellectual property. So, they can choose to license it how they wish, encode it or not, have it audited or not, etc etc. If we were to put strict rules on 3rd-party extensions, it would result in fewer such extensions being available and still be no guarantee that the ones available, and audited, with our seal of approval could never be exploited. There is some risk with any software, so it's up to people to assess that risk and make decisions on what to use. I like the idea of an optional, paid "Certified by Blesta" process for extensions, because it's voluntary and ensures people that the code was reviewed by Blesta developers and meets our standards for security or code styling. This can add value to 3rd-party extensions by creating a level of trust with users, but there would be a cost associated and it wouldn't make sense for obscure or open source extensions. "Certified by Blesta" is not something we would require though, because it would have a negative impact on the availability of extensions. We want to make it as easy as possible for 3rd parties to create more extensions, not less.

"Deliver Invoices" and "Create Invoices" are different. The Create Invoices task actually generates the invoice, via recurring services or recurring invoices. Deliver Invoices actually sends it, as is the one that runs every 5 minutes. Create Invoices runs once per day. I hope that makes sense and glad that it seems to be working for you now!

Merchant payment gateways do not show the name. For example, the customer will never see "Authorize.net", but rather "Credit Card". So, I see this exclusively for non-merchant gateways, and the example of showing simply "PayPal" instead of "PayPal Payments Standard" and "Bitcoin" instead of "Bitpay" are excellent examples. If we have to localize the names of gateways, then that sort of pushes us toward language files. I'm not convinced that gateway names like "PayPal" or "2Checkout" translate well into other languages. Are they not known by their names in other languages? The simplest solution is to be able to set a single name to "override" the build in gateway name. So, for non-merchant gateways, we could potentially add a new field when managing the gateway called something like "Display Name", which would default to the gateway name. For PayPal, this might say "PayPal Payments Standard", but could be modified to say anything you want. Thoughts on this kind of implementation?

It doesn't matter if it's in public_html, because the subdomain will have its own docroot. I suspect the redirect is happening outside of Blesta.

Do you think the name the customer sees should be part of the language file, included with the gateway? Or should you be able to specify the name manually when configuring the gateway? I'm not sure most gateways would need to be translated. Authorize.net, PayPal, these names are universal are they not?

Make sure the paths are correct under Settings > System > General. Make sure there are no other .htaccess files that may be creating a loop scenario.

Nice work, looks really clean!

See CORE-2295 and let us know if you have any suggestions on how we can improve the task.

I like it, congrats on the new display name! Blesta Addons

Yes sir it should! Please feel free to test it out on the v4 beta if you have the time to do so.

So, Proforma invoices should not be calculated in the outstanding balance, the same as planned for "Pending" invoices, aka invoices with future bill dates? Please confirm, and I'll modify the task, assuming this is a standard requirement. It seems to make sense, since it's not forcibly due.

I would enable error reporting in /config/blesta.php (change error reporting from "0" to "-1" value). Then, disable the cron temporarily, and run it manually when the next backup should be processed. Settings > System > Automation. It may output more errors. If the issue is only when your CLI/cron environment runs it, and not via Web, then you can execute the same cron command via SSH/CLI instead.

The License Manager for licensing your own software is a paid addon ($100 one-time), which you can add to your owned license by clicking Manage next to your license in the client area, then Addons on the left, then select it from the drop down. Once purchased, you'll have access to it within the Downloads section where you can grab it and install. The mass mailer plugin is included in 4.0, and is part of the current 4.0.0-b3 beta release. It will not work on 3.6, but you can try it out on the beta.

See CORE-1805. As of 3.6.0-b1, scheduling cancellation for a parent service, should automatically set the same cancellation date for addons.

Looking at the gateway logs, was the first attempt the successful one for the full amount? After that, the gateway would normally (for authnet anyway) return a duplicate transaction error. Your logs would be most helpful in determining what may have happened here.

Yes, they would necessarily have to be able to see a history of all their orders. Do you think this is best as a new widget on the client dashboard, or better as a new page? Could be a dropdown option under the new "Order" nav link in the client area, that shows "Order History" or something. They could view all orders, and cancel only incomplete orders. Thoughts?

Thanks Mike, I'll just add, re #2. We can audit the code for a module or plugin for a fee, and label it as "Certified by Blesta". We haven't done this yet for any 3rd party extensions, but we're open to the idea. Re #6. Maybe. This would be on a case-by case basis. But, in large, our recommendation is that the developer release the extension as FOSS on Github.

Please post beta bugs in the beta bug forum - https://www.blesta.com/forums/index.php?/forum/37-bugs/