Commit Graph

13251 Commits

Author SHA1 Message Date
FusionPBX 9a7b2071af Update app_defaults.php 2019-07-02 12:58:20 -06:00
FusionPBX 892c94abd9 Update app_defaults.php 2019-07-02 12:57:15 -06:00
FusionPBX e7fac86e7c Update app_defaults.php 2019-07-02 12:53:23 -06:00
FusionPBX b84423dfde Update app_defaults.php 2019-07-02 12:37:10 -06:00
Len f4216dc7a5 Update app_config.php (#4325) 2019-07-02 11:19:25 -06:00
Len c00dda8b99 Update {$mac}.cfg (#4326) 2019-07-02 11:18:57 -06:00
Len 9e75b31d78 Update {$mac}.cfg (#4327) 2019-07-02 11:18:19 -06:00
Nate d50170269e Database class integration. 2019-07-02 10:56:36 -06:00
Nate f7742bef81 Call Broadcast delete fix. 2019-07-02 08:51:19 -06:00
Nate e18f1ef537 Database class integration. 2019-07-02 08:44:23 -06:00
Nate 8882502cc6 Database class integration. 2019-07-01 21:10:31 -06:00
Nate fad7c24b90 limit_offset() function refinement 2019-07-01 20:52:54 -06:00
Nate 492d03a5b9 Allow underscore in order_by() function. 2019-07-01 20:37:34 -06:00
Nate 747b0ff3d8 Misc. 2019-07-01 17:32:08 -06:00
Nate d075a083cf Database class integration. Create order_by() and limit_offset() functions. 2019-07-01 17:30:03 -06:00
Nate 32b04431f7 Fix typo in select() method switch statement. 2019-07-01 13:26:26 -06:00
FusionPBX 5541785b95 Update app_config.php 2019-07-01 10:37:39 -06:00
FusionPBX fa8fd98fc9 Update app_config.php 2019-07-01 09:55:12 -06:00
FusionPBX 738bcb0ba2 Update app_config.php 2019-07-01 09:52:11 -06:00
Nate a591c87776 Database Class Support for "...ies" Table Names (#4321)
Currently, the permission checks within the class try to singularize the table name, then check for permissions based on the result.  This PR modifies the private singular() function to support table names that end in "...ies", where an _add or _edit permission likely uses a 'y' instead.  An example would be where inserting records into v_event_categories, the class should probably look for an "event_category_add" permission, instead of "event_categorie_add".  Likewise for update queries.  

This proposed change isn't foolproof, obviously. In the case of inserting or updating records in a table named v_pies, it would fail to suffice.  You're welcome to integrate a better solution, if one exists.
2019-06-30 15:11:15 -06:00
mtghr 4480563044 Update {$mac}.cfg (#4061)
* Update {$mac}.cfg

Polycom will not support wild  card cert only if you disable strictCertCommonNameValidation

also polycom is missing many root  certs so we need an option to push them via the template 

bot stuff was tested by me in  production and its working fine

* Use isset
2019-06-29 13:40:11 -06:00
Chris Black e630208bb9 Update {$mac}.cfg (#4287)
add line key to T54s
2019-06-29 13:32:41 -06:00
Len 3477842f51 Update {$mac}.xml (#4316) 2019-06-29 13:30:31 -06:00
Len 3691c0ece1 Update {$mac}.xml (#4317) 2019-06-29 13:29:55 -06:00
Len baef31c370 Update {$mac}.xml (#4318) 2019-06-29 13:29:34 -06:00
Len db46983ba8 Update {$mac}.xml (#4319) 2019-06-29 13:29:22 -06:00
Len 85d779c190 Update {$mac}.xml (#4320) 2019-06-29 13:28:41 -06:00
FusionPBX 50187b2caf Update {$mac}.cfg 2019-06-29 12:14:05 -06:00
FusionPBX 53b6ba2e57 Update {$mac}.cfg 2019-06-29 12:13:03 -06:00
FusionPBX f738b297b0 Update app_config.php 2019-06-29 12:11:14 -06:00
FusionPBX ac98f4cb5a Update {$mac}.cfg 2019-06-29 12:02:58 -06:00
FusionPBX 3824e5ec33 Update {$mac}.cfg 2019-06-29 11:59:46 -06:00
FusionPBX 38d8120bfe Update index.lua 2019-06-28 13:12:04 -06:00
FusionPBX 0587461e65 Update destinations.php 2019-06-28 09:43:32 -06:00
FusionPBX 7918358124 Update functions.php 2019-06-27 10:16:43 -06:00
FusionPBX eb0d39f1f9 Update xml_cdr_inc.php 2019-06-27 09:05:06 -06:00
FusionPBX 61965dd69c Update dialplans.php 2019-06-27 08:35:31 -06:00
FusionPBX 84caa1bd6a Update dialplans.php 2019-06-27 08:08:41 -06:00
FusionPBX 4ec5b0e17a Update app_config.php 2019-06-27 07:55:39 -06:00
ednt 31170138e7 A typo at the last commit (#4313) 2019-06-27 07:06:40 -06:00
Len d939aaaeb7 Create {$mac}.xml (#4306) 2019-06-26 23:57:07 -06:00
Len 4d954b27d5 Create {$mac}.xml (#4307) 2019-06-26 23:56:48 -06:00
Len d099272778 Create {$mac}.xml (#4308) 2019-06-25 12:34:16 -06:00
Len 5fb80c530c Create {$mac}.xml (#4310) 2019-06-25 12:34:00 -06:00
Len eadeea6138 Create {$mac}.xml (#4305) 2019-06-25 11:47:59 -06:00
Len c532440a51 Create {$mac}.xml (#4309) 2019-06-25 11:47:27 -06:00
Len 8ec112c687 Update {$mac}.xml (#4304) 2019-06-24 21:34:11 -06:00
FusionPBX 63876aa86c Update cmd.php 2019-06-23 14:51:28 -06:00
emaktech f44ed4370c Fix Ring Group Delay Timing (#4003)
This is going to sound really stupid but I have tested this extensively, submitted a Jira on it months ago (was told FS 1.6.20 was no longer supported) and it's still an issue. Please do not take my word for this and create a ring group to test the delay settings with a stopwatch and you should see the real vs set delay discrepancy.

In FreeSWITCH (both on 1.6.20 and 1.8.5) when sending leg_delay_start values, for whatever reason the actual time is double the value sent. The result of this is that if you send 1000ms as leg_delay_start the actual time the call will be delayed is 2000ms.

Because of this bad behavior, ring group delay settings end up being exactly double what is set. e.g. if you set 10s, you will have to wait 20s for the call to be initiated on leg b.

The easiest way to fix this behavior is to simply multiply leg_delay_start by half as much to get the right "real" delay time. Ugly, I know... I'm not sure if leg_delay_start value is passed elsewhere, I'm thinking this behavior may also be present in find me/follow me. If this gets accepted I will look for other locations where this behavior occurs and submit separate PRs if I find any other instances of this.
2019-06-21 22:04:14 -06:00
Len d74a8eedf0 Update {$mac}.xml (#4302) 2019-06-21 22:02:50 -06:00