FusionPBX's current stable release (when writing this article) is 4.4.4. So far the best FreeSWITCH fronted I have ever found. However, there is no flawless software, and because of the highly complex structure within, FusionPBX is no exception.
The hardest part in FusionPBX, in my opinion, is keeping track when upgrading legacy systems. There are many factors: dial-plans get upgraded but old tenants don't get them, LUA scripts are updated, and FreeSWITCH upgrades all these conduct to variables change and then, new software looking for variables that are not provided by old dial-plans is one of the darkest places to look for a bug.
I will write here about two issues I found: first, regarding the EYE icon, then about the CDR when recording the calls.
Detailed CDR Shows an Empty Page
When you go to the Call Detailed Record Menu, you will see all your calls. If you are having this issue, when you click on the eye icon you will see an empty page with no information.
This is caused because, in the v_xml_cdr table, the json field has its content escaped. Like this \{\"propierty\":\"value\"\}. The json_decode function returns a null instead of an error or an exception. The FusionPBX doesn't verify what happens.
To fix this, I just called the stripslashes() function. Voilà, it is fixed. I have sent pull requests #4051 and #4052 to fix this. They were accepted.
Recordings not Shown in the CDR
First, we are 100% sure the file exists and it is not a filesystem permission issue. After that, you will notice that on some domains the recordings are not shown but the actual file exists.
The root cause of this problem is that record_name and record_path variables are not set in the dial plans, therefore the CDR Importer fails to feed the database. The FusionPBX code verifies the existence of the record_session variable and it assumes the other record_* ones exist. Therefore, it tries to call dirname(urldecode(null)) and basename(urldecode(null)). Then, it just reviews for an isset()sset() which it fails because the variable exists isset() will return true, but it has an empty value or null one.
Then, the fix is not only verifying for isset() but for is_null() and strlen() == 0. Pull requests #4053 and #4054 have been sent to fix this issue. When writing this article, they haven't been accepted yet. I will update the post if they are accepted.
UPDATE: April, 20th 2019. These pull requests have been accepted.
Do not hesitate to contact me about fixing your deployments.
Good luck!
";