Tyson

In order to understand recursion, one must first understand recursion.

Thanks, CORE-2683

Don't link an `id_value` column to anything. It relates no table records, rather it is a derived value used in conjunction with `id_format`.

What did you do to fix this? Bracket characters (i.e. "[" and "]") are valid ASCII characters, so does Logicboxes define a set of valid characters suitable for the address fields?

If you set a private key passphrase you are preventing Blesta from running cards automatically, and you should process cards manually under Billing > Batch. Hopefully the note at the top of that page is clear: WARNING: Setting a passphrase will prevent locally stored payment accounts from being automatically processed. You will be required to manually batch payments by entering your passphrase.

If those session values, session.gc_probability and session.gc_divisor were set to 0, then the session's garbage collector was disabled which explains the large amount of old sessions in the system. Did you update all of your Blesta servers to ensure they have these values set? Those are php's default values, which give the garbage collector a 1% chance of running when someone connects, so that sounds good. No, I don't think you should empty the table manually unless you are out of disk space and need to clean something up. It would be best to observe that the php garbage collector clears the old session data on its own. Since it was only a couple days since you updated those php settings , the garbage collector may not have actually run yet since it only has a 1% chance to based on user activity. I would give it some more time to see whether it eventually deletes those old records by itself. You could also increase the probability of it running the garbage collector, e.g., set session.gc_probability to 100 to force the garbage collector to run 100% of the time. It should then clear the old session records, however, you should change the session.gc_probability back to 1 afterward.

Blesta overrides the session.gc_maxlifetime value, but how often the garbage collector runs is determined by the session.gc_probability and session.gc_divisor. I checked other Blesta installations from v4.0 to v4.3 and the garbage collector is running for all of them, so it might be that garbage collection is disabled in your environment?

What about php's configured garbage collection settings? It is odd that you have so many records that haven't been purged by now. My dev installation only has a couple weeks of session information.

What are the configured values for your session TTL and cookie TTL in your /config/blesta.php? php's garbage collector will only look at removing session data older than those values, and it has a small probability to run, so it's possible records that old are still kept based on your Blesta TTLs and the php server's configuration for garbage collection.

Under what circumstances do you notice the system hanging? Perhaps a cron task is taking a lot of resources at that particular time? If so, it'd be useful to know what cron task is currently running. The following query may help you identify any running cron tasks if executed when you notice the performance degradation SELECT `cron_tasks`.* FROM `log_cron` INNER JOIN `cron_task_runs` ON `cron_task_runs`.`id` = `log_cron`.`run_id` INNER JOIN `cron_tasks` ON `cron_tasks`.`id` = `cron_task_runs`.`task_id` WHERE `log_cron`.`end_date` IS NULL AND `log_cron`.`run_id` != 0;

Is this a module's validateService method, or the Service model's validateService method? Under what conditions do you see a difference?

So yes, Authorize.net now requires your server communicate over TLS 1.2. They have dropped support for TLS 1.0 and 1.1. If you haven't already, contact your hosting provider and tell them that you need support for TLS 1.2 and they should either add support for that or move your account over to a server that does.

That error regarding the module row being unavailable sounds like an issue with the package. Is the package configured to use the Centovacast module and a specific server (i.e. the module row)? Is a server configured for the module under Settings > Modules > Centovacast (Manage button)? If your trial is about to expire, email sales at blesta.com and we'll be happy to extend it for you to finish testing the software.

The two applications don't share identical hashing algorithms or secret keys so they wouldn't generate the same hashed passwords, nor should they. This is more of a use case solvable using a single sign-on approach instead, i.e., create the user in Blesta with a random password and when they log in to Laravel have them initialize a session with their account in Blesta using the Shared Login plugin.

The mcrypt extension may increase performance for encryption in some cases, but it is not required.

If you haven't resolved this issue yet, you may want to contact DirectAdmin support for help. The module POSTs a suspension via the API command CMD_API_SELECT_USERS, with a location set to CMD_SELECT_USERS. Normally, this would suspend the user in DirectAdmin and respond back to Blesta that there was no error performing this action, however, the DirectAdmin API returned an invalid HTML response that is not expected for that end point, which leads me to believe that the DirectAdmin API or or its configuration has gone awry.

We resolved that issue with the dialog box not appearing for v4.3.0. It appears to affect the Chrome browser.

We have plans to include client information in the email template if it is available, but the {ticket.email} tag wouldn't be updated to include the email address unless the ticket/reply was emailed in.

tl;dr Sometimes staff don't like to be woken up at home. Example: Go to Support > Staff > Edit (one of the staff users). Notice that there are several checkboxes representing different ticket priorities you can select (e.g. "Emergency", "Critical", etc.) Some Staff may want to receive all of those ticket notifications to their work email at their work computer when they're at work. However, when they're at home sleeping, they may not want their phone to wake them up because of a ticket notification unless it is an "Emergency" ticket that they need to deal with. That page allows them to configure the ticket notice emails they will receive. The Order email is similar, but you configure your settings for that under Billing > Overview > (click the settings/gear icon at the top right of the Orders widget).

Based on that log response, it looks like TCAdmin did respond that it setup the account. Are you not seeing it in TCAdmin or is the service still pending in Blesta, or..?

The client should still be able to log in to the system. Blesta does not validate the user's email address on log in, but only that their username matches.

Yes, they are already in the config file, however, there is no distinction made between admins or clients in the session TTL. Open your config file /config/blesta.php and update the session/cookie TTL values: // Length of time (in seconds) that a session will be valid for Configure::set('Blesta.session_ttl', 1800); // 30 minutes // Length of time (in seconds) that a cookie will be valid for Configure::set('Blesta.cookie_ttl', 604800); // 7 days

Could you elaborate on your need to override the user's language in preAction? Do you have a link to an example?

The language is set after that event is called now because Blesta sets the staff and client language based on configured values/session information.

That does seem to look like a problem with the LogicBoxes Reloaded module. Each task should at least read "Attempting to process <task>." followed eventually by "The process <task> task has completed." This indicates the task both started and completed successfully. If you do not see that the task has completed, it is either still running (unlikely) or there was a failure processing the task that stopped php execution.