Commit Graph

137 Commits

Author SHA1 Message Date
Andrew Querol b67d55b39c
Replace duplicated v_xml_cdr_import.php with a call to the post method of xml_cdr (#5956)
* Redirect duplicated xml_cdr_import script

This replaces the duplicated code in v_xml_cdr_import.php with xml_cdr_import.php

This also adds a call to `$cdr->post();` in that file to then process the POSTed data from FreeSWITCH
2021-05-26 09:54:08 -06:00
FusionPBX b2e0402478
Get the call_center_queue_uuid from the channel variables. 2021-05-21 13:16:18 -06:00
markjcrane 8bd751f1c9 Use the cc_queue to get the call_center_queue_uuid 2021-05-07 22:04:38 -06:00
markjcrane 9cfd41d222 Update CDR imports fix syntax 2021-05-07 16:06:03 -06:00
markjcrane cfd70fb18f Use the queue uuid for the cc_queue 2021-05-06 23:23:07 -06:00
demonspork c11589b1c3 Track Voicemail Message Success/Failure in CDR
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.
2021-02-21 21:09:37 -06:00
demonspork 0ef2551698 Exclude cc_side agent legs from missed_call
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.
2021-02-21 18:26:24 -06:00
demonspork ef38b15cdc Add new missed call rules to HTTP CDR Imports
Add new missed call rules to HTTP CDR Imports. They had only been added to the xml_cdr class used by the file import.
2021-02-20 11:51:24 -06:00
demonspork 1a1edf1195 Improved Missed Call accuracy, cdr statistics, and hide duplicated CDRs from Enterprise Ring Groups
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;
```
2021-02-20 11:51:24 -06:00
FusionPBX c314f4352a
Minor change add a little better description. 2020-12-10 20:20:51 -07:00
FusionPBX e1f428db59
Add direction inbound for call center calls and update missed_calls. 2020-07-02 18:01:59 -06:00
FusionPBX 8aa4277449
Update v_xml_cdr_import.php 2020-05-06 14:23:17 -06:00
FusionPBX 71e861a68c
Update v_xml_cdr_import.php 2020-05-06 14:19:28 -06:00
FusionPBX d53c90d1dd
Update v_xml_cdr_import.php 2020-04-28 16:15:18 -06:00
FusionPBX f18e578892
Update v_xml_cdr_import.php 2020-04-17 12:51:49 -06:00
FusionPBX 0028e9cf50
Update v_xml_cdr_import.php 2020-04-17 12:33:57 -06:00
FusionPBX 4b2a918193 Update v_xml_cdr_import.php 2020-03-10 10:41:38 -06:00
FusionPBX 00656120ef Update v_xml_cdr_import.php 2020-01-31 16:36:03 -07:00
Andy-Seattle cfd70dcf4e E.164 Inbound caller ID fix (#5138)
When an inbound call has E.164 caller ID format (eg Skyetel), the + is being stripped from the caller_id_number variable before storing in the v_xml_cdr database table. If we then try and block this CDR in the Call Block application it adds the number BUT without the + so it never matches future calls.
This proposed change ensures that the + is not stripped for INBOUND calls when written to v_xml_cdr and therefore when blocking the CDR it works correctly (i.e. it includes the + which then matches the call next time and blocks it).
2020-01-31 15:37:46 -07:00
FusionPBX 3ef8a0ae12 Update v_xml_cdr_import.php 2019-12-23 11:23:53 -07:00
FusionPBX 71479d69fc Update v_xml_cdr_import.php 2019-12-23 11:17:34 -07:00
FusionPBX 11f80ba1bf Update v_xml_cdr_import.php 2019-10-07 23:43:02 -06:00
FusionPBX 1c0368cb5f Update v_xml_cdr_import.php 2019-10-07 23:37:53 -06:00
FusionPBX cc6a5758fb Update v_xml_cdr_import.php 2019-10-07 14:55:20 -06:00
FusionPBX a1164b4999 Update v_xml_cdr_import.php 2019-10-07 13:17:21 -06:00
FusionPBX 24a3028092 Update v_xml_cdr_import.php 2019-09-03 13:21:06 -06:00
FusionPBX 0597179a1c Remove the 3rd party billing system
A better way to integrate 3rd party billing is is to create own CDR import code to fit their needs.
2019-09-03 08:53:11 -06:00
Luis Daniel Lucio Quiroz 186d7981a2 [4.5] fixes null record_name and record_path fields in v_xml_cdr (#4053)
* 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.
2019-04-20 17:05:40 -06:00
konradSC 7eafc693c4 Bug fix: No answer_stamp in CDR (#4049)
* 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
2019-04-11 18:00:11 -06:00
FusionPBX 185b28cacc Update v_xml_cdr_import.php 2019-03-17 00:51:06 -06:00
FusionPBX 05d2d4ca98 Update v_xml_cdr_import.php 2019-03-17 00:49:43 -06:00
FusionPBX e48256aee5 Update v_xml_cdr_import.php 2019-03-16 04:17:01 -06:00
FusionPBX e6ad6ef488 Update v_xml_cdr_import.php 2019-03-14 14:57:46 -06:00
FusionPBX 1a40dfe9ee Update v_xml_cdr_import.php 2018-10-24 10:51:56 -06:00
FusionPBX 32f794fb3f Update v_xml_cdr_import.php 2018-10-17 22:03:31 -06:00
FusionPBX 711e008b3a Update v_xml_cdr_import.php 2018-10-17 15:45:23 -06:00
FusionPBX dc2925e922 Update v_xml_cdr_import.php 2018-10-17 15:41:14 -06:00
FusionPBX 9eb861e971 Update v_xml_cdr_import.php 2018-07-02 21:01:37 -06:00
FusionPBX 6a46b541dc Update v_xml_cdr_import.php 2018-05-19 16:59:24 -06:00
FusionPBX eaea0d53c5 Update v_xml_cdr_import.php 2018-05-09 16:48:20 -06:00
FusionPBX 910ba8fd08 Update v_xml_cdr_import.php 2018-04-22 11:51:36 -06:00
FusionPBX 093f9d3f0a Update v_xml_cdr_import.php 2018-04-18 16:29:57 -06:00
FusionPBX 37a83627ce Update v_xml_cdr_import.php 2018-04-18 11:52:45 -06:00
FusionPBX fcda5def50 Update v_xml_cdr_import.php 2018-03-15 23:21:56 -06:00
FusionPBX 14155c1ded Update v_xml_cdr_import.php 2018-02-23 08:40:25 -07:00
FusionPBX 11bfa81edd Update v_xml_cdr_import.php 2018-02-13 10:17:14 -07:00
FusionPBX e6a5299593 Update v_xml_cdr_import.php 2018-02-05 13:26:30 -07:00
FusionPBX 0703fce4d2 Update v_xml_cdr_import.php 2018-01-29 17:30:12 -07:00
FusionPBX 8e4fb530fa Update v_xml_cdr_import.php 2017-10-20 18:02:58 -06:00
FusionPBX 23428c82ee Update v_xml_cdr_import.php 2017-10-20 17:57:57 -06:00