Escaped Characters in Dialplan Not Working Correctly Anymore

[GoogleCodeExporter]

Currently updated to r1516, but I noticed some recent changes to the Dialplan 
code has resulted in the necessity to escape some of my regex strings.  

For example, in the preset for 'recordings', the 'destination_number' and 
^*(732)$ is causing an issues.  I need to manually change this to ^\*(732)$

Another example is that the '*' character in the follow me in the 
'follow_me_XXXXX.park' dialplan, which is generated when follow me calling 
details change, needs data in the destination_number condition to be escaped.

When I tried to edit the condition through the web based interface 
'https://1.2.3.4/mod/dialplan/v_dialplan_includes_details_edit.php?id=80&id2=11'
, wasn't able to do so and I received a 500 Internal Server Error.

So, I had to svn update -R1509 to get everything to function again.  I didn't 
try any of the revisions between 1510 and 1515 to see when the bug was actually 
introduced.

Original issue reported on code.google.com by br...@uniteddiamonds.com on 6 Sep 2011 at 5:17

[GoogleCodeExporter]

What database are you using?

If sqlite you wouldn't be having this problem.

If MySQL then you need to make sure that the MySQL driver is installed it is a 
requirement for mysql_real_escape_string. You can check if it is installed by 
going to Advanced -> Command -> PHP Command and run the following: phpinfo();

Original comment by markjcrane@gmail.com on 6 Sep 2011 at 3:44

[GoogleCodeExporter]

I'm using a postgres DB.

Original comment by br...@uniteddiamonds.com on 6 Sep 2011 at 3:50

[GoogleCodeExporter]

The code now uses pg_escape_string to escape the values in the sql statements. 
When you reported this problem I went into the dialplan details page and it had 
a problem loading which was caused by a missing ". Please update with: svn 
update then report back whether you are still experiencing the problem you 
reported.

http://us.php.net/pg_escape_string

Original comment by markjcrane@gmail.com on 6 Sep 2011 at 4:33

[GoogleCodeExporter]

The latest update committed resolves this issue earlier reported.  Thanks for 
the quick turnaround.

I have a question related to "best practices".  Should I continue to 'escape' 
my special characters through the web interface?  If so, I think the fresh 
installation should have these default dialplans already populated with the '\' 
escape character in the condition fields.

Actually, I think this is from FS, correct?  If so, then maybe this discussion 
should take issue 77 (http://code.google.com/p/fusionpbx/issues/detail?id=77) 
into consideration.

Original comment by uniteddi...@gmail.com on 6 Sep 2011 at 4:49

[GoogleCodeExporter]

This bug has been confirmed to be fixed. I'm updating the status.

Original comment by markjcrane@gmail.com on 16 Sep 2011 at 9:30

• Changed state: Fixed