Customer Service Reporting

I'm not sure this really belongs as part of this tool, but perhaps in a different tool.

What I do on my current system is monthly I zip the previous months recording and move the files to an NAS that is protected from disk failure by RAID. I think everyone might have a sightly different way of handling this because the methods of transfer may be different.

Maybe if we created a new tool that just zipped up the previous month's recordings automatically. Then users can transfer those files away or leave them there if they want.

As I write this, I wonder if this sort of functionality my be better as part of some sort of backup module. I know there have been a couple of back-up solutions created, but I don't know if they are FreePBX modules. This sort of file maintenance might fit better as part of a backup solution though.

I agree- its an odd fit in some ways. If we give the user the opportunity to disable this function - we wont cause any problems, and having it there might solve some. There is no other interface driven way to manage these left over files. How would you feel about it in these terms?

Ok - One more reason to consider this. In one of the vertical markets we serve, there is a common export data file type that is used by several data processing proceedures during the life of the task. At each point in the process where the exported data is used by another program, the application has the option of deleting the export file (so they don't build up forever). The key is that ONLY the final consumer of the export file actually performs the deletion.

The circumstance for the build op of the recorded call files is similar. There may be one, or more than one purpose to have these files saved. Each point in the process should have the OPTION to delete the files.

In this way, a site that ONLY records calls for the purpose of using this module could ENABLE this modules ability to delete files older than X days. However, at a site where these recordings have a purpose beyond this modules use of them, then the modules ability to delete the recordings is left DISABLED, and some other user/process is responsible to clean them up.

The result of us NOT giving the module the ability to manage these files will be some less astute PBX operator will run out of space on their hard drive one day and be clueless as to WHY. The only slightly more astute operator might simply have to forgo using the module unless it does the entire job and manages its own leftover audio files - since they don't know how to create a cron task or script to do it themselves.

I realize that allowing the module to delete older recordings is not a full deluxe solution - and that an app to manage areas of the pbx like this might be desirable in the future. But this option has zero downside, and its absence might be a showstopper for many.

Please consider adding this to a future release.

Jeremy - Still not feeling the love for this? Having these files build up is going to be a real thorn in the side for some folks. If we let them select the number of days, and let them turn it off and on - Give it some thought. I think we really need to address this - and the cron task would be easy enough to manage -. Any traction here at all? :)

There doesn't seem to be a good way to 'play nice' - if we start deleting recordings, we affect the entire system. This should probably be done elsewhere. Perhaps another module to manage cron jobs designed to delete recordings by date, etc.