Cody

Permissions are so dependent on the system using them, and since Blesta's API is so extensive, it would be cumbersom, both from a UI perspective, and from an implementation perspective to add permissions for all supported actions. You're best bet is a plugin. It gives you the control and isolation to ensure permissions are enforced as your business requirements dictate, and it doesn't requiring evaluating thousands of individual permission options to setup. Not only that, but Blesta's API is an every evoling thing. So it really isn't a good idea to allow third parties to use it directly. We use the plugin option for controlling access with our own internal and external integrations, and we really wouldn't want it any other way.

Attached is a test script you can execute on your server to help diagnose issues with setting include paths. To use, unzip test_include_path.zip, then run it once via your web server, and via CLI. You should have the same exact result for each, printing "SUCCESS!!" at the bottom. php test_include_path.php Expected output: php test_include_path.php Current include path: .:/usr/bin/pear Modifying include path to include: /var/www/html/include_path_test/includes Include path is now: .:/usr/bin/pear:/var/www/html/include_path_test/includes Success. Attempting to a include file. Should print "SUCCESS!!" below... SUCCESS!! If you don't receive a success, your php.ini file is configured improperly, or your user does not have permission to execute files. include_path_test.zip

Version 3.4.0 is now available. You can download it in the Client Area. Installing Blesta See Installing Blesta in the User Manual for instructions. Upgrading Blesta See Upgrading Blesta in the User Manual for instructions. Migrating to Blesta See Migrating to Blesta in the User Manual for instructions. Overview Client Contact Logins Two Factor Authentication for Clients and Contacts Knowledgebase via the Support Manager plugin Tons more... PHP 5.5+ Users Included in this release is a /hotfix-php5.5/ directory. Please use this directory to overwrite the default /blesta/app/app_controller.php, /blesta/app/app_model.php, and /blesta/app/models/license.php files. Release Notes See Blesta Core - Version 3.4.0-b1. See Blesta Core - Version 3.4.0-b2. See Blesta Core - Version 3.4.0. For older releases see all Change Logs.

Version 3.3.2 is now available. You can download it in the Client Area. This is a patch release that corrects issues with 3.3.0. Patching Blesta See Patching Blesta in the User Manual for instructions. Release Notes See Blesta Core - Version 3.3.2. See all Change Logs.

CORE-1498 is closed as Won't Fix. It sounds like you're attempting to submit a form without a CSRF token, which is not allowed. Submit a feature request to add what you're trying to accomplish correctly (recommended), or explicitly exclude the controller and action from CSRF check in /config/blesta.php (not recommended).

We have definitely improved the language, putting the letter z to good use and removing unnecessary u's. I realize green is a color.

In the US all school children are taught and memorize all 50 states, and these correlate to ISO 3166-2 subdivisions perfectly. So it's a little funny to see the confusion between what you, as UK residents, expect vs. what the ISO and your BSI has defined for the UK.

Has nothing to do with the AJAX request, rather you don't see the result of the AJAX request because your server chokes on the actual SFTP action. If you're familiar with browser inspectors you could see the result returned from the server (if it returns anything). You should enable PHP error logging on your server and log all PHP errors. You can also open the /config/blesta.php config and change the error reporting value from 0 to -1 at the top of that file.

The test makes an AJAX request. Sounds like your server is choking on the request. Could be your server is missing or has an outdated version of the openssl or curl PHP extensions.

No, that's not the point at all. The point is to defer the responsibility of keeping that card data secure to the gateway, which reduces your liability should your database be leaked.

If you allow users to enter credit card numbers at your domain name, then yes you should obtain PCI compliance scans.

You can use the CLI API to interact with models. You can also execute controllers via CLI: % php /path/to/blesta/index.php controller/action param1 param2 param3 This is how cron jobs are executed (e.g. php /path/to/blesta/index.php cron) You could create a plugin which would give you an environment to execute whatever you want via CLI: % php /path/to/blesta/index.php plugin/plugin_name/controller_name/action The above assume the following in /path/to/blesta/plugins/plugin_name/controller_name.php: <?php class ControllerName extends AppController { public function index() { echo "the default action"; } public function action() { echo "a different action"; } }

The customer token, account token, last 4 of card number, card expiration date.

Blesta doesn't pass the email address to Authorize.net. Authorize.net only uses the email address to send purchase receipt emails which is super awkward for clients. Blesta handles purchase receipts, so no need to use that "feature" of Authorize.net.

This is the result of the migrator not being able to find the pricing ID for the configurable option imported from WHMCS, when attempting to add the configurable option for a service. This could mean that either: The service has a config option set that doesn't exist SELECT tblhostingconfigoptions.* FROM tblhostingconfigoptions INNER JOIN tblhosting ON tblhosting.id=tblhostingconfigoptions.relid LEFT JOIN tblproductconfigoptions ON tblproductconfigoptions.id=tblhostingconfigoptions.configid LEFT JOIN tblproductconfigoptionssub ON tblproductconfigoptionssub.id=tblhostingconfigoptions.optionid WHERE tblproductconfigoptions.id IS NULL OR tblproductconfigoptionssub.id IS NULL; The config option exists, but the pricing doesn't -- pricing set but no config value defined SELECT tblpricing.* FROM tblpricing LEFT JOIN tblproductconfigoptionssub ON tblproductconfigoptionssub.id=tblpricing.relid WHERE tblpricing.type='configoptions' AND tblproductconfigoptionssub.id IS NULL; Pricing exists, but the config option doesn't -- config value set but no pricing defined for one or more currencies SELECT tblproductconfigoptionssub.*, tblcurrencies.code AS currency_code, tblcurrencies.id AS currency_id FROM tblcurrencies JOIN tblproductconfigoptionssub LEFT JOIN tblpricing ON tblpricing.relid=tblproductconfigoptionssub.id AND tblpricing.type='configoptions' AND tblcurrencies.id=tblpricing.currency WHERE tblpricing.id IS NULL;

Version 3.3.1 is now available. You can download it in the Client Area. This is a patch release that corrects issues with 3.3.0. Patching Blesta See Patching Blesta in the User Manual for instructions. Release Notes See Blesta Core - Version 3.3.1. See all Change Logs.

Yup, every merchant gateway works that way.

Check the mail log under [Tools] > [Logs] > . Do you see anything in there?

You could use a coupon that only applies if both Hosting B and Domain are added together.

What's your definition of non-recurring automatic payments? Any payment processed through a merchant gateway can be processed by Blesta automatically when Blesta determines the payment should be processed.

Update /components/gateways/nonmerchant/offline/views/default/process.pdt. From: <?php echo $this->TextParser->encode("markdown", $this->Html->ifSet($meta['instructions'])); ?> To: <?php echo $this->Html->ifSet($meta['instructions']); ?> But I HIGHLY RECOMMEND you clone the offline gateway and rename it to create your own custom gateway if you need iframes. This offline gateway only supports Markdown text.

The offline payment gateway is only intended to support Markdown text. See Markdown syntax Here's an example: # This is a heading This is a paragraph - List item 1 - List item 2 1. Number list 1 2. Number list 2 [Text to link](http://google.com/) Produces: <h1>This is a heading</h1> <p>This is a paragraph</p> <ul> <li>List item 1</li> <li>List item 2</li> </ul> <ol> <li>Number list 1</li> <li>Number list 2</li> </ol> <p><a href="http://google.com/">Text to link</a></p>

That's not true. <?php $this->Form->fieldPassword("field_name", array('value' => "field_value")); ?>

The enom module already encrypts the API key. The only other module data stored is the username and whether or not sandbox should be used. Neither of which need to be encrypted. It's important to keep in mind that encrypted text is unsearchable.

Yes, definitely always use https whenever at all possible.