I have a unique situation where I have had to revert to my backup FusionPBX server running on a VPS instance. I was working remotely for 7 months and while away from home, my FusionPBX hardware box was not set up properly to deal with power outages as far as starting back up when the power restored as well as my UPS not behaving so I registered my phones where I was to my VPS instance and routed the incoming calls to that server. The trouble is that I am able to save the records in csv or pdf but there is no clean way to import them without dumping the database and importing just the cdr.
I notice that the php file is actually there. I tried manually adding it to the main CDR php file and listing only the superuser. In the group permissions I see the entry and it defaults to superuser being able to use it and I even made a menu entry to point to it. I am not using the old V file that points to the new one. I am able to see it in the menu and I get access denied. The third party solution that has a centos RPM didn't work either and yes, I made sure that the permissions are correct. I'm missing something. I am doing this on my VPS instance since I can just restore a snapshot if the system becomes too far removed.
I created this thread hoping markjcrane will read it. I am not interested in other PBX software other than to test it on the side which I have done with 3cx and others so keep those in the other threads. There must be a reason why cdr import is not active. I don't know if it ever was. Overall I've been very happy with FusionPBX on top of Freeswitch and Debian. I'm doing some things on this that I may not be able to do on the commercial stuff such as exporting variables in my dial plans, namely for my extensions that are used for fax. It took a lot of work. Faxes are still used in the legal and medical industries. You don't email medical and sensitive legal documents. You might as well just display them in Times Square.
I export several T38 parameters only for the extensions that have the fax ata channels. Combined with a Netgen ATA that is designed for FOIP, I have faxes about as reliable as the PSTN faxes and I get T38 fax calls more often than not since every leg supports it now most positively, even with toll free calls. I had to add four specific outbound routes with the variables for 7, 10, 11 digits, and toll free calls coming from the extensions that are fax only and then the variables are exported on incoming to those same extensions. I actually get incoming T38 faxes through Bandwidth despite them not saying anything. The g.711 faxes thanks to the ATA I am using work reliably as well. Yes I use ECM. Most FOIP guides are completely wrong including Bandwidth's old document. If a fax fails with ECC it's because it failed for a good reason, you are sending them gobbledygook. If you care about the recipient being able to get an error free readable copy you will keep the ECM enabled. The other method of disabling so more faxes go through is very flawed concept. It means you don't care so long as they receive something. It's like removing a car air filter in a dust storm so that the engine will breathe no matter what but I digress.
I notice that the php file is actually there. I tried manually adding it to the main CDR php file and listing only the superuser. In the group permissions I see the entry and it defaults to superuser being able to use it and I even made a menu entry to point to it. I am not using the old V file that points to the new one. I am able to see it in the menu and I get access denied. The third party solution that has a centos RPM didn't work either and yes, I made sure that the permissions are correct. I'm missing something. I am doing this on my VPS instance since I can just restore a snapshot if the system becomes too far removed.
I created this thread hoping markjcrane will read it. I am not interested in other PBX software other than to test it on the side which I have done with 3cx and others so keep those in the other threads. There must be a reason why cdr import is not active. I don't know if it ever was. Overall I've been very happy with FusionPBX on top of Freeswitch and Debian. I'm doing some things on this that I may not be able to do on the commercial stuff such as exporting variables in my dial plans, namely for my extensions that are used for fax. It took a lot of work. Faxes are still used in the legal and medical industries. You don't email medical and sensitive legal documents. You might as well just display them in Times Square.
I export several T38 parameters only for the extensions that have the fax ata channels. Combined with a Netgen ATA that is designed for FOIP, I have faxes about as reliable as the PSTN faxes and I get T38 fax calls more often than not since every leg supports it now most positively, even with toll free calls. I had to add four specific outbound routes with the variables for 7, 10, 11 digits, and toll free calls coming from the extensions that are fax only and then the variables are exported on incoming to those same extensions. I actually get incoming T38 faxes through Bandwidth despite them not saying anything. The g.711 faxes thanks to the ATA I am using work reliably as well. Yes I use ECM. Most FOIP guides are completely wrong including Bandwidth's old document. If a fax fails with ECC it's because it failed for a good reason, you are sending them gobbledygook. If you care about the recipient being able to get an error free readable copy you will keep the ECM enabled. The other method of disabling so more faxes go through is very flawed concept. It means you don't care so long as they receive something. It's like removing a car air filter in a dust storm so that the engine will breathe no matter what but I digress.