Leaderboard

Hello, There is a simple fix that I have added to Support Manager Pro in my latest update Its because the CSS Position: fixed, has to be changed into Position: absolute The problem is the position of the box that will Drop to the end of the page but will always be visible in all browsers Hope that helps

@Paul I am grateful to see Blesta looking to adhere to GDPR: https://dev.blesta.com/browse/CORE-2463 Thank you. However, it is still important for Administrators to be able to delete old (redundant) client information, to comply with UK Data Protection Laws, which will still apply alongside GDPR. Therefore, it seems an opportune time to incorporate the necessary features at the same time as CORE-2463, as there is overlap. To that end, the way I see this implemented is as follows: A Company setting called "Client cleanup". In Client Cleanup setting; specify number of days to delete clients considered to be redundant. 0 = never, 1826 = 5 years. You have a granular setting to select the Client Groups that the client cleanup will effect. This allows clients to be protected from deletion, if required for a particular purpose (that hasn't been considered). The client cleanup will be an automated task, run once a day. The client cleanup will work on clients with the following conditions met: 1. Marked as inactive in Blesta (which the admin does manually), 2. Has no active services, 3. Their last invoice was closed X days ago (as per number of days set in Client cleanup setting), 4. In client group(s) X (as per client groups set in client cleanup setting). For example, this is how I see it operating: You enable client cleanup by setting the company setting with the number of days that you want to cleanup redundant clients. eg. I set 1826 = 5 years (Blesta would ship with this setting disabled by default by having it set to 0). You then choose the "Default" client group and this will mean that the client cleanup will look for clients in the Default client group -> for any that have been marked as inactive -> have no active services -> their last invoice was closed 1826 days ago. It is debatable as to whether there is the requirement for the client to first be manually marked by the Admin as inactive. It doesn't matter either way, but could be a useful safeguard - comments on this? This comment is duplicated at: https://requests.blesta.com/topic/delete-client-for-data-protection-reasons (posted here for awareness)

I fixed the bug by doing this in direct_admin_api.php: 'suspendUser' => array('POST','','CMD_API_SELECT_USERS',array('suspend'=>'Suspend','location'=>'CMD_API_SELECT_USERS')), 'unsuspendUser' => array('POST','','CMD_API_SELECT_USERS',array('suspend'=>'Unsuspend','location'=>'CMD_API_SELECT_USERS')), from: 'suspendUser' => array('POST','','CMD_API_SELECT_USERS',array('suspend'=>'Suspend','location'=>'CMD_SELECT_USERS')), 'unsuspendUser' => array('POST','','CMD_API_SELECT_USERS',array('suspend'=>'Unsuspend','location'=>'CMD_SELECT_USERS')), that was likely a oversight on the blesta dev's part but is actually easily to fix as shown above, since directadmin's api information here: http://www.directadmin.com/features.php?id=807 states the default CMD_SELECT_USERS will not return the standard json api response like the module is expecting, CMD_API_SELECT_USERS does return the standard json api response and therefore it works finally, tried to find the module on github to submit a pull request to apply this patch to module but didn't find it so thought would just post it here instead. thanks to @Doctrine for providing the directadmin panel to patch the issue and make sure it works. information redacted for security reasons.

I just set up a fresh v4.2.0 install. The MySQL database password contains the character "$" which was stored in config/blesta.php as "\$". This made sense in older versions as the config options were surrounded by double quotes in v3.6.?, but it appears they've been changed to single quotes which led to me banging my head for a minute trying to figure out why I was only getting blank pages. <?php //... Configure::set('Blesta.database_info', [ //... 'pass' => '\$abc123', //... ] );

Thanks for the report, we'll take a look. CORE-2594

Expanding on this at some point would be nice but I still personally think the domain manager is a bigger priority.

Encrypting a large amount of data on the fly with PHP is not feasible as it's incredibly slow. However, it might be possible to use openssl on the linux system to perform the encryption, prior to securely transferring it to a remote location. I found this article that describes that https://blog.cavebeat.org/2016/02/encrypted-backups-with-secure-mysqldump/