* Hide Extension Summary button show all by default. Add new permission xml_cdr_extension_summary_all
Many extensions and CDR records make this a resource very intensive query. Disable by default for all groups.
* Add new permission xml_cdr_extension_summary_all
* Update xml_cdr_extension_summary.php
* Update xml_cdr.php
When an inbound call is forwarded the call_direction is set to inbound and then updated to outbound. In this situation we use the sip_from_display and sip_from_user to get the original caller ID instead of the updated caller ID after the call was forwarded.
* Use epoch times for CDR Imports
There has been some discussion of edge cases for CDR Importing time zones/time stamps.
This modification makes the start_stamp, answer_stamp, and end_stamp values use the corresponding _epoch times for import into the v_xml_cdr table to remove any chance of time zone mis-alignment.
* Set Call recording date with Epoch
Use the start_epoch to set the call recording date.
Track whether or not a message was actually left in the voicemail box. Previously we only knew that voicemail answered, now we know whether the caller left a message.
Callers who didn't leave a message now show up in the "Cancelled" call filter in xml_cdr.php
Bonus: Fixed a bug with the originating_leg_uuid that was breaking extension summary from a previous commit and some other minor bugs/typos.
Excluded cc_side = agent calls from being marked as missed_call = true
Fixed the previous performance issue with adding the cc_side != 'agent' to the SQL and removed its filter from the rendering loop for the xml_cdr.
It is redundant to filter out LOSE_RACE when originating_leg_uuid is also filtered, there is an overlap where every call with LOSE_RACE also has an originating_leg.
Changes
--------
- Improve CDR Import Logic so that missed_call column is more accurate to the "missed" status. It would previously mark unanswered outbound calls as "missed". These are their own category of call.
- Don't mark the CDRs of the "legs" of an Enterprise Ring Group call as missed, only the originating_leg will be marked (one missed call per call) - We could also just "skip" importing these call legs. Simultaneous ring groups don't have these duplicated CDRs for every ringing phone. The "Skip" approach might make most of the rest of this work irrelevant.
- Create `originating_leg_uuid` column in v_xml_cdr and import it into the database during CDR imports so it is available for filtering Enterprise Ring Group calls out of CDRs and reports.
- Move logic that hides the agent leg of CC calls, LOSE_RACE calls, and the Enterprise Leg hiding code from xml_cdr.php into xml_cdr_inc.php into the SQL query WHERE clause so the CDR page looks more consistent. The logic is the same, but these calls are now excluded from the query result entirely instead of having to "skip" rendering them in the list on the xml_cdr.php page.
- Improved CDR statistics page to use the missed_call variable instead of relying upon billsec and answer_stamp/answer_epoch. Added the same logic as the xml_cdr pages to the query so it excludes enterprise ring group call legs.
- Laid the query groundwork in xml_cdr_statistics to report on Average TTA (No UI changes yet to include that statistic)
Retroactive Changes
---------------------
There are a few changes going back in time to bring everything in line with this better reporting accuracy:
- If you want the populated the `originating_leg_uuid column` in `v_xml_cdr`, it will rely upon having the `json` column and not having deleted the data from it like I know some people do for space saving.
- If you don't have the json column, you are mostly out of luck for hiding the duplicate legs of Enterprise ring group calls. It might be possible, but it isn't going to be easy.
- On Newer Versions of postgres, this works:
```
UPDATE v_xml_cdr SET originating_leg_uuid = (json->'variables'->>'originating_leg_uuid')::uuid WHERE json->'variables'->>'originating_leg_uuid' IS NOT NULL;
```
- For some reason on postgres 9.4, I had to UPDATE every single record because I couldn't get it to allow the json syntax properly after the WHERE. This is fine, it doesn't change the end result it just means it has to run the UPDATE on every record, which will take a while
```
UPDATE v_xml_cdr SET originating_leg_uuid = (json->'variables'->>'originating_leg_uuid')::uuid;
```
- To remove the `missed_call = true` on all your previous outbound records so that they don't show up when you filter on missed (outbound unanswered calls can be accurately listed with TTA max 0 and direction outbound)
```
UPDATE v_xml_cdr SET missed_call = false WHERE direction = 'outbound' AND missed_call = true;
```
Null UUID's are not very kind. They will sneak into your CDR's when you aren't looking and break an otherwise very nice database INSERT statement. We cannot tolerate that sort of behavior.
* record_name verification
* record_name better verification
when you carry on some updates from 4.0 to 4.2 and then 4.4, old dialplans do not create all the variables, record_session is created, but record_name (and record_path) are not null, set and lenght zero, "" in otherwords.
Then, in the db record, record_name and record_path are empty, regardless if the recording file exists. Therefore, they are not shown in the CDR app.
This fixes this issue.
* Bug fix: No answer_stamp in CDR
Here's a fun little bug that took me a longer than it should have to figure out. When a person make a call and then cancels the request there is no "answer_stamp" written to the CDR. Because of this, v_call_recordings.call_recording_name gets imported as NULL. This causes all the canceled calls to show up in the Call Recordings app first in the list and with no date set.
* Update xml_cdr.php
* Update v_xml_cdr_import.php
Add check for duplicate call records. Duplicate records will cause the entire db insert to fail. I have tested this with the /app/xml_cdr/xml_cdr_import.php method for cdr insertion.
This grabs a recording if started by bind_digit_action "*2" or by "nolocal:api_on_answer=uuid_record ${uuid} start ${recordings_dir}/${domain_name}/archive/${strftime(%Y)}/${strftime(%b)}/${strftime(%d)}/${uuid}.${record_ext}".