I’m thinking he means how long to keep/or remove call records, within the pbx itself
Ah oh, ok sorry. I thought he was talking about the recording module 
. My fault. Yes, that should be possible.
BTW, the PR still hasn’t been reviewed. So I have a few modules pending.
Tssss…
It would be pretty easy to add a cron job the module would kick off that deletes records older than what date you specify. The module would also have to delete the cron job and resubmit it when a user changes the purge criteria. A bash scrip could pretty well do that mysql stuff to delete the older CDR and CEL records on a daily, weekly, monthly or annual basis.
However, A such feature already exist.
Advensed Settings / CDR /
Transient CDR data retention
KEYWORD:TRANSIENTCDRDATA
How many days cdr need to keep in transient cdr
doing well @franck.danard aka Captain Crepe 
. Not so much the transient used for phones, but the primary CDR (and CEL for that matter), if you Google around, you see many remedies, but nothing simple. I also believe the latest implementation of MariaDB in 17 actually allows for the file to shrink in size as well, whereas in the past, you could remove the records with no impact on the ibdata file size. I always looked at it as an unmanaged log.
Tom said it well here
The transient_cdr table is a poor work around to not having proper CDR retention logic in FreePBX. It holds the last 60 days of CDR records so the API and other queries don’t get bogged down by a massive CDR table.
Of course, if you need more than 60 days…you still have to do with a massive CDR table.
Anyway, with respect to the changes in 17 to innodb
17
MariaDB [(none)]> SHOW VARIABLES LIKE ‘innodb_file_per_table’;
±----------------------±------+
| Variable_name | Value |
±----------------------±------+
| innodb_file_per_table | ON |
±----------------------±------+
vs 16
MariaDB [(none)]> SHOW VARIABLES LIKE ‘innodb_file_per_table’;
±----------------------±------+
| Variable_name | Value |
±----------------------±------+
| innodb_file_per_table | OFF |
±----------------------±------+
AI overview below:
The ibdata1 file in MySQL/MariaDB serves as the shared system tablespace for InnoDB, containing data dictionary, undo logs, and potentially data and indexes for tables if innodb_file_per_table is not enabled. While TRUNCATE TABLEoperations can remove data from tables, they do not inherently reduce the size of ibdata1 if the table’s data and indexes reside within the shared system tablespace.
Hmm. This means that if you delete 500MB of data, the disk space in the database will still be 500MB.
I know that with some older databases, you have to reindex them, or reindex the table, to reduce the storage space.
@franck.danard - yes, for 16 that was the case. In 17, it’s not, and table optimization will reclaim the space, making it available to the system.
Checking in on this! 
I appreciate that you are working to continue to be innovative with FreePBX
Thanks so much.
Yes, I try to work on FreePBX systems whenever possible in my free time. How stupid is it to abandon this old module with its ugly interface without reviewing the design and functionality.
However, I need to fixe some stuff and it should be ready to go
1 Like