Ticket #5473 (new Bugs)

Opened 1 year ago

Last modified 1 year ago

Bad Dest in IVR when destination is long Custom Destination

Reported by: schneisasg Assigned to:
Priority: minor Milestone: Undetermined
Component: IVR Version: 2.9-branch
Keywords: Cc:
Confirmation: Unreviewed Distro:
Backend Engine: All Distro Ver:
Backend Ver: SVN Revision (if applicable):

Description

When using a Custom Destination that is fairly long (more than 50 characters) as a destination within an IVR, the IVR will always truncate the text (preventing the desired behavior) and throw a Bad Dest error.

Looking at the MySQL schema, it appears that the custom_dest column in the custom_destinations table allows up to 80 characters for the destination. While in the ivr_dests table, the dest column only allows 50 characters.

mysql> show columns from custom_destinations;
+-------------+--------------+------+-----+---------+-------+
| Field       | Type         | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+-------+
| custom_dest | varchar(80)  | NO   | PRI |         |       |
| description | varchar(40)  | NO   |     |         |       |
| notes       | varchar(255) | NO   |     |         |       |
+-------------+--------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

mysql> show columns from ivr_dests;
+-----------+-------------+------+-----+---------+-------+
| Field     | Type        | Null | Key | Default | Extra |
+-----------+-------------+------+-----+---------+-------+
| ivr_id    | int(11)     | NO   |     | NULL    |       |
| selection | varchar(10) | YES  |     | NULL    |       |
| dest      | varchar(50) | YES  |     | NULL    |       |
| ivr_ret   | tinyint(1)  | NO   |     | 0       |       |
+-----------+-------------+------+-----+---------+-------+
4 rows in set (0.00 sec)

This appears to allow working past the problem:

alter table ivr_dests change dest dest varchar(80);

Change History

(in reply to: ↑ description ) 05/17/12 19:38:50 changed by schneisasg

This same issue is also a problem with incoming routes in v2.10.

This change to SQL appears to work around the issue:

alter table incoming change destination destination varchar(80);

Given that the original ticket was opened more than 5 months ago, and the solution is pretty simple, I'd hoped this would have been looked at by now.