Paul

How often do you come across this issue? As you mentioned, it can take some time to provision a service. The status in not updated until it is completed. I think this would necessitate, potentially, a new status for services that are being activated such that when the cron STARTS to activate a pending service, its status is changed to this new status, and when the cron finishes activating a service, it's status is changed to active. In this way, a service that is in the process of being activated would not be pending, and we could check when manually activating that it's in a status of pending before proceeding. I'm not sure what other implications this has, other than the possibility that a service "disappears" should the cron crash in the middle of provisioning.

Here's a custom report for exporting client data that matches a specific list of comma separated package ID's. This is useful for exporting client data, and importing with the Blesta CSV importer into a new Blesta install. Does not import actual services/packages, which would have to be moved manually. To create the custom report, go to Billing > Reports, and click on the "Customize" tab, then the [+] button. 1. Give the report a name, like "Client Export from Package IDs" 2. Enter the following query into the Query text area: SELECT `contacts`.`first_name`, `contacts`.`last_name`, `contacts`.`company`, `contacts`.`title`, `contacts`.`address1`, `contacts`.`address2`, `contacts`.`city`, `contacts`.`country`, `contacts`.`state`, `contacts`.`zip`, `contacts`.`email`, `users`.`username` FROM `packages` INNER JOIN `package_pricing` ON `package_pricing`.`package_id` = `packages`.`id` INNER JOIN `services` ON `services`.`pricing_id` = `package_pricing`.`id` AND `services`.`status` = 'active' INNER JOIN `clients` ON `clients`.`id` = `services`.`client_id` INNER JOIN `users` ON `users`.`id` = `clients`.`user_id` INNER JOIN `contacts` ON `contacts`.`client_id` = `clients`.`id` AND `contacts`.`contact_type` = 'primary' WHERE `packages`.`id` IN (:package_ids) GROUP BY `clients`.`id`; 3. Create a field with a Label of "Package Ids", Name of "package_ids", Type of "Text", and Required: "Yes" 4. Save. The report will now be available under the "Generate" tab. When generating the report, enter package ids as a comma separated list (e.g. 23,24,81). NOTE! The Package ID is the internal ID, not the Package ID listed for the package listing. Hover over the Edit link, or click it to observe the actual ID of the package in the URL.

You cannot do a fresh install and then import your database. The encryption keys in your database will not match the system key in your config file (/config/blesta.php) and you will permanently break your installation. You can re-upload all of the files for 4.1.0, but you must keep the key in your config, and it must match your database.

I'm sure there will be an official announcement soon, but LC isn't going anywhere.

Just to be clear, this happens if you are managing the pending service where the "Activate" button appears when the service is activated by the cron, and then you click "Activate", it will create a second service? If that's the case, I suppose when clicking the "Activate" button, we could check that the service is still in a pending state.

+1 for this, iDev is fully featured and has more features than ours will have.

Did you apply the php7-hotfix included with 4.1.0? Sounds like the fix for PHP 7 was not applied when you were upgrading.

What version of Blesta are you using? There was a bug in, I believe, 4.0.0 that prevented that from loading if the servers were not in a server group. Even if you're not running 4.0.0, if your Interworx server is not in a group I would suggest adding it to a group and see if selecting the group will cause the Interworx Packages to load. If you are running 4.0.0, I'd suggest upgrading to 4.0.1 at minimum (4.1.0 preferably).

I have marked it as planned. Also, CORE-1091. Domain manager is a higher priority, but this one is getting up there also.

Try changing it to 0. The error message will be the same regardless of the minLength, but this is the only location within the directadmin module that sets a requirement of 5.. so this must be it. Otherwise, it's your DA server returning the error, but I doubt it. (You could confirm by checking the module log Tools > Logs > Module Log) When you edit the service, do you see the password asterisked out in the password field? ************ If this field is empty, it explains the error.

Yes that's correct. Are these long passwords stored in Blesta, or only on DA's side? Blesta is checking the password length as it is stored locally.

That's probably why. The importer is intended to be used with a fresh install of Blesta.

direct_admin.php defines a minLength of 5 for the direct_admin_password. Search ~/components/modules/direct_admin/direct_admin.php for "minLength", and you'll see a value of 5. You could try decreasing this temporarily to say 1 and see if that allows you to change the server. When finished, I'd suggest changing the value back.

A new Square gateway (alpha) is available for testing. To install, download the attached , square.zip unzip and upload the "square" directory to ~/components/gateways/nonmerchant/ and visit Settings > Company > Payment Gateways to install and configure.

I ran the import without error, it went smoothly for me, so I'm not sure why you got the error.. unless it was an older version of the importer. The updates we made in 4.1.0 final seem to work pretty well, and I haven't come across an import I've attempted that has failed in that version yet.

I think it's a good idea. +1

The task is open., but yeah it's been in there for a while. Hasn't been a high priority.

I mentioned this to @Jono and he was going to create a task and investigate.

I'm glad we were able to help get the data imported!

A lot of companies are "one-man shows", there's nothing wrong with that. It's probably not a good idea to pretend there are a lot of people if there isn't, it's a bit dishonest, but I understand why they do. People tend to look down on "one-man shows", and I think in most cases that's unjustified.

Are you seeing this with another official module? Or is it happening with a custom module that has no module rows?

If you can send the login to an SFTP server you operate that would be great. PM me either the user or pass, and email sales or support at blesta.com the rest of the info so it's split up. It's the end of the day here now, but we could do this in the morning around 9 or 10am pacific time so if it's available then, great.

Invalid user ID? This should be resolved in 4.1.0 final. Are you certain that it's not one of the beta releases? If you would like, we can take a backup of your whmcs database and perform the export here, and send you the Blesta database that results securely via SFTP. If we run into any errors during the import, we'll correct them, and update the importer if necessary. And, of course, delete everything when we are done.

Just re-save your staff group. Settings > System > Staff > Staff Groups. Edit and save without any changes

Staff all use the default language. We do have a task for staff to be able to select their own independent language. Once this is added, then it would be possible to change the default language. See CORE-1750