Tyson

The client interface will be on bootstrap while the admin interface will remain the same. We presume roughly 8 weeks between minor releases, which would put v3.2 around the Ides of March. We prefer a date of "when it's ready".

Unchecked checkboxes are not submitted via POST, so yes, there wouldn't even be a record of it. If there were, then to the OP's question, there would need to be a checked and unchecked value.

Actually, you may be experiencing this bug.

Yes, we would like to improve the module to have better support for KVM/HVM, but we currently lack a testing environment for those virtualization types.

Custom field checkboxes only have one value--the value when the box is checked. You can set it to anything you like. If you leave the value blank, then the value stored will be blank when the box is checked.

What setting values are saved for the cron task? Did it happen to run once, but stall?

Can't say I've experienced this. I would need to know how you have your packages/addon packages setup to duplicate this, but from other addons I have, I'm not able to reproduce the problem. Try enabling error reporting in php and then go back to that page to look for errors.

What's the error that is displayed?

The seconds are optional. Looks like the regex has an issue, though. It would expect the format "##:##:" or "##:##:##". The last colon should be optional. You can fix it by moving the question mark to the right 1 character. CORE-1040

Part of being "Visible to Client" means that they should see it. The distinction that they should not see it on the client registration order form if it is disabled may not be what most people expect. I'd be curious to hear what people think about this, or if it's preferred to have a new setting to make that distinction. I'd recommend opening a feature request for this. As for the original bug report, I'm going to close this thread as not a bug.

I thought we would have had something there. It certainly worked for me at least. If you can provide a Blesta admin account and FTP access to update the cPanel module, I can take a look.

Okay, let's try one more change. If you could, update /components/modules/cpanel/cpanel.php (line 1475) and change: $this->log($row->meta->host_name, $response, "output", $success); to: $this->log(($row ? $row->meta->host_name : "unknown"), $response, "output", $success); And see if the packages load this time.

I'm not able to duplicate this issue. Read only works fine for me. What browser are you using? Does it support the 'disabled' attribute on input fields? Are you sure you're viewing the correct order form for the client group for which you setup the read only custom field?

Interesting. So, the Input is fine, but there is no Output section. Either an error occurred, or the cPanel server didn't respond to the request. I don't think it would have been an error, otherwise you likely would have seen it on the Packages page. Do you have multiple cPanel servers listed under [settings] -> [Company] -> [Modules] -> [installed] -> cPanel? Can you re-save them successfully? Do you have a server group created that your package is using, but which you forgot to assign servers to?

If the service has been down intermittently, then the task could still be running, waiting for a response. I imagine it would have eventually timed out. It's also possible that the task could have experienced a fatal error only when run in CLI mode automatically when the cron runs. In the case of the latter, you can pipe the cron output to a file on your server and then take a look at it if you experience this problem again to see if there are any errors.

Fixed in CORE-1013 for v3.1.1.

Do you know whether the reseller account has privileges to call "listaccts" via the API?

Thanks for the steps to duplicate. I've fixed this in CORE-1032 for v3.1.1. If you want to fix this yourself, you can update the following files: Update /app/views/admin/default/admin_clients_addservice_confirm.pdt (line 76) and change: if ($this->Html->ifSet($addon->package_options && $this->Html->ifSet($addon->configoptions))) { to: if ($this->Html->ifSet($addon->package_options) && $this->Html->ifSet($addon->configoptions)) { You may receive a separate error as well, that you can fix by updating /app/controllers/admin_clients.php (line 4137) and changing: $addon->package_options = $this->PackageOptions->getByPackageId($addon->id); to: $addon->package_options = $this->PackageOptions->getByPackageId($addon->package_id);

If you are logging cron output on your server, you can check the server logs to see what the error may be. Alternatively, when the task fails to run, you could email in a ticket yourself, delete the task from the database as I described above, and then run the cron manually through the admin interface. Assuming that having a ticket ready to be imported causes the issue, you should be able to see the error in the admin interface. Also, you could probably have your cronjob setup to write to a file (or email you) rather than go to /dev/null, so you can view the output from the cron. Since you don't see the link on the company Automation page to clear the task, the task is failing, and causing the rest of the company tasks to fail, which sounds like a fatal error. Blesta can't log fatal errors, so you'll need to look outside of Blesta for that information.

Since the issue is recurring, it sounds as if you have a larger issue, possibly an error occurring when the cron executes up to that point. Since you don't see the link to clear the task, you should delete this task from the log_cron table and run the cron manually through the admin interface. You should be able to run the following query and then delete all of the results. It usually goes without saying, but you should backup the database before making manual changes. SELECT * FROM `log_cron` WHERE `run_id` !=0 AND `end_date` IS NULL ORDER BY `start_date` DESC; Then go to [settings] -> [system] -> [Automation] and run the cron manually. If there is an error, you should see it there, and then we can come up with a solution.

A link to clear a task will appear next to it on the Automation page if Blesta determined that the task has stalled. It sounds like: the task was still actually running the cron had not yet finished running other tasks in the same group or you had another issue that prevented the cron from finishing Manually updating the database to clear this problem is not necessary, as you can do so through the interface, as long as you don't encounter one of the above 3 conditions.

I think this is the reason it currently works this way.

If you can retrieve the packages via the API in Blesta v2.5, then I'm not sure why it's not working in v3. However, I don't think this action is logged. We would need to know what the response is from the server when attempting to fetch the packages to see what the cause may be. If you can update a file to add in logging, then please update /components/modules/cpanel/cpanel.php (line 1521) and change: return $this->ArrayHelper->numericToKey($this->Json->decode($api->listpkgs())->package, 'name', 'name'); to: $this->log($module_row->meta->host_name . "|listpkgs", null, "input", true); $result = $this->parseResponse($api->listpkgs()); if (!$result || !property_exists($result, "package")) return array(); return $this->ArrayHelper->numericToKey($result->package, "name", "name"); Then, go to add/edit a cPanel package, and then check the Module Logs. Let us know what output is shown.

Thanks, I've added this as CORE-1031 to look into it.

It's scheduled for v3.2, but may get pushed back.