2.8 dial pattern and rules
I applaud the efforts to make things easier to understand but when it makes hard to work with I frown.
Before I could cut and paste many rules and patterns with a click or 2 now I have to enter every one manually, a real pain.
Also how follow the howto "http://www.freepbx.org/support/documentation/howtos/how-to-set-up-per-use-caller-id-blocking-67" and enter the waits. it does not seem to accept any.
Perhaps the text box should remain....
__________________
News Announcements
New Forum Topics
- no inbound calls showing up in monitor section
- Yum won't update
- Need ability to have weather announcment on a special voicemail.
- Disabling Enum
- End-Point-Manager over Internet
- Freepbx 2.10 Recordings portal not working
- Error with style after upgrade
- Soft phone for iphone
- hi ,can anyone help me please ,i want to add custom port 7060 after my domin
- only group 0 shows up in trunk drop down list.
- Day/Night BLF
- Errors with "ARI" After update, Asterisk Failure and Interface won't load
Unfortunately there can
Unfortunately there can sometimes be a trade-off between ease of use and understanding for less experienced users and vs. efficiency when dealing with more "complex" tasks for more advanced users.
We had several discussions when making this change for some of the very reasons you bring up. My personal preference is the "textarea" that was previously there as it is much easier for me to do things like you describe.
However, this is one of the most confusing areas for many users, both new and those who have been using FreePBX for some time. Even with the changes it it still often hard to understand the flow of outbound routes + trunks in conjunction with the dial rules and patter manipulation. However, feedback has indicated that it has at least improved a notch which is a step in the right direction.
Given that setting these up is not something that is done on a regular basis, as routes and trunks are usually configured and then forgotten, it was considered the right step to take when looking at both the positives and negatives that it brought.
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
Very sad indeed. we could
Very sad indeed. we could have it both ways so why not leave the text input for those that know what they are doing together with the new stuff for those with no clue.
But thank for your comments.
we didn't leave it for a
we didn't leave it for a couple reasons.
One is simply the support headache of two different sets of code that do the same thing, as the code to process the textarea vs. the new format is quite different.
The other is that the new GUI has introduced a bit more functionality for both outbound routes and trunks.
When we looked at all the pros vs. cons, the positive effect of the change far outweighed the negative effect, it's not like it was close...
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
Is there a screenshot
Is there a screenshot somewhere that shows the difference? Here's the reason I ask: For security and cost-control reasons, I have three different outbound routes (actually more than that, but only there three are germane to the issue). In one route I have a pattern for every valid US area code, expressed as 10 or 11 digits. It looks like this:
1201NXXXXXX
1202NXXXXXX
1203NXXXXXX
1205NXXXXXX
1206NXXXXXX
1207NXXXXXX
1208NXXXXXX
1209NXXXXXX
1210NXXXXXX
1212NXXXXXX
1213NXXXXXX
1214NXXXXXX
1215NXXXXXX
1216NXXXXXX
1217NXXXXXX
1218NXXXXXX
1219NXXXXXX
1224NXXXXXX
1225NXXXXXX
1228NXXXXXX
1229NXXXXXX
1231NXXXXXX
1234NXXXXXX
1239NXXXXXX
1240NXXXXXX
1248NXXXXXX
1251NXXXXXX
1252NXXXXXX
1253NXXXXXX
1254NXXXXXX
1256NXXXXXX
1260NXXXXXX
1262NXXXXXX
1267NXXXXXX
1269NXXXXXX
1270NXXXXXX
1274NXXXXXX
1276NXXXXXX
1281NXXXXXX
1301NXXXXXX
1302NXXXXXX
1303NXXXXXX
1304NXXXXXX
1305NXXXXXX
1307NXXXXXX
1308NXXXXXX
1309NXXXXXX
1310NXXXXXX
1312NXXXXXX
1313NXXXXXX
1314NXXXXXX
1315NXXXXXX
1316NXXXXXX
1317NXXXXXX
1318NXXXXXX
1319NXXXXXX
1320NXXXXXX
1321NXXXXXX
1323NXXXXXX
1325NXXXXXX
1330NXXXXXX
1331NXXXXXX
1334NXXXXXX
1336NXXXXXX
1337NXXXXXX
1339NXXXXXX
1347NXXXXXX
1351NXXXXXX
1352NXXXXXX
1360NXXXXXX
1361NXXXXXX
1364NXXXXXX
1385NXXXXXX
1386NXXXXXX
1401NXXXXXX
1402NXXXXXX
1404NXXXXXX
1405NXXXXXX
1406NXXXXXX
1407NXXXXXX
1408NXXXXXX
1409NXXXXXX
1410NXXXXXX
1412NXXXXXX
1413NXXXXXX
1414NXXXXXX
1415NXXXXXX
1417NXXXXXX
1419NXXXXXX
1423NXXXXXX
1424NXXXXXX
1425NXXXXXX
1430NXXXXXX
1432NXXXXXX
1434NXXXXXX
1435NXXXXXX
1440NXXXXXX
1442NXXXXXX
1443NXXXXXX
1458NXXXXXX
1469NXXXXXX
1470NXXXXXX
1478NXXXXXX
1479NXXXXXX
1480NXXXXXX
1484NXXXXXX
1501NXXXXXX
1502NXXXXXX
1503NXXXXXX
1504NXXXXXX
1505NXXXXXX
1507NXXXXXX
1508NXXXXXX
1509NXXXXXX
1510NXXXXXX
1512NXXXXXX
1513NXXXXXX
1515NXXXXXX
1516NXXXXXX
1517NXXXXXX
1518NXXXXXX
1520NXXXXXX
1530NXXXXXX
1534NXXXXXX
1540NXXXXXX
1541NXXXXXX
1551NXXXXXX
1559NXXXXXX
1561NXXXXXX
1562NXXXXXX
1563NXXXXXX
1567NXXXXXX
1570NXXXXXX
1571NXXXXXX
1573NXXXXXX
1574NXXXXXX
1575NXXXXXX
1580NXXXXXX
1585NXXXXXX
1586NXXXXXX
1601NXXXXXX
1602NXXXXXX
1603NXXXXXX
1605NXXXXXX
1606NXXXXXX
1607NXXXXXX
1608NXXXXXX
1609NXXXXXX
1610NXXXXXX
1612NXXXXXX
1614NXXXXXX
1615NXXXXXX
1616NXXXXXX
1617NXXXXXX
1618NXXXXXX
1619NXXXXXX
1620NXXXXXX
1623NXXXXXX
1626NXXXXXX
1630NXXXXXX
1631NXXXXXX
1636NXXXXXX
1641NXXXXXX
1646NXXXXXX
1650NXXXXXX
1651NXXXXXX
1657NXXXXXX
1660NXXXXXX
1661NXXXXXX
1662NXXXXXX
1678NXXXXXX
1681NXXXXXX
1682NXXXXXX
1701NXXXXXX
1702NXXXXXX
1703NXXXXXX
1704NXXXXXX
1706NXXXXXX
1707NXXXXXX
1708NXXXXXX
1712NXXXXXX
1713NXXXXXX
1714NXXXXXX
1715NXXXXXX
1716NXXXXXX
1717NXXXXXX
1718NXXXXXX
1719NXXXXXX
1720NXXXXXX
1724NXXXXXX
1727NXXXXXX
1731NXXXXXX
1732NXXXXXX
1734NXXXXXX
1740NXXXXXX
1747NXXXXXX
1754NXXXXXX
1757NXXXXXX
1760NXXXXXX
1762NXXXXXX
1763NXXXXXX
1765NXXXXXX
1769NXXXXXX
1770NXXXXXX
1772NXXXXXX
1773NXXXXXX
1774NXXXXXX
1775NXXXXXX
1779NXXXXXX
1781NXXXXXX
1785NXXXXXX
1786NXXXXXX
1801NXXXXXX
1802NXXXXXX
1803NXXXXXX
1804NXXXXXX
1805NXXXXXX
1806NXXXXXX
1808NXXXXXX
1810NXXXXXX
1812NXXXXXX
1813NXXXXXX
1814NXXXXXX
1815NXXXXXX
1816NXXXXXX
1817NXXXXXX
1818NXXXXXX
1828NXXXXXX
1830NXXXXXX
1831NXXXXXX
1832NXXXXXX
1843NXXXXXX
1845NXXXXXX
1847NXXXXXX
1848NXXXXXX
1850NXXXXXX
1856NXXXXXX
1857NXXXXXX
1858NXXXXXX
1859NXXXXXX
1860NXXXXXX
1862NXXXXXX
1863NXXXXXX
1864NXXXXXX
1865NXXXXXX
1870NXXXXXX
1878NXXXXXX
1901NXXXXXX
1903NXXXXXX
1904NXXXXXX
1906NXXXXXX
1907NXXXXXX
1908NXXXXXX
1909NXXXXXX
1910NXXXXXX
1912NXXXXXX
1913NXXXXXX
1914NXXXXXX
1915NXXXXXX
1916NXXXXXX
1917NXXXXXX
1918NXXXXXX
1919NXXXXXX
1920NXXXXXX
1925NXXXXXX
1928NXXXXXX
1931NXXXXXX
1936NXXXXXX
1937NXXXXXX
1940NXXXXXX
1941NXXXXXX
1947NXXXXXX
1949NXXXXXX
1951NXXXXXX
1952NXXXXXX
1954NXXXXXX
1956NXXXXXX
1970NXXXXXX
1971NXXXXXX
1972NXXXXXX
1973NXXXXXX
1978NXXXXXX
1979NXXXXXX
1980NXXXXXX
1985NXXXXXX
1989NXXXXXX
201NXXXXXX
202NXXXXXX
203NXXXXXX
205NXXXXXX
206NXXXXXX
207NXXXXXX
208NXXXXXX
209NXXXXXX
210NXXXXXX
212NXXXXXX
213NXXXXXX
214NXXXXXX
215NXXXXXX
216NXXXXXX
217NXXXXXX
218NXXXXXX
219NXXXXXX
224NXXXXXX
225NXXXXXX
228NXXXXXX
229NXXXXXX
231NXXXXXX
234NXXXXXX
239NXXXXXX
240NXXXXXX
248NXXXXXX
251NXXXXXX
252NXXXXXX
253NXXXXXX
254NXXXXXX
256NXXXXXX
260NXXXXXX
262NXXXXXX
267NXXXXXX
269NXXXXXX
270NXXXXXX
274NXXXXXX
276NXXXXXX
281NXXXXXX
301NXXXXXX
302NXXXXXX
303NXXXXXX
304NXXXXXX
305NXXXXXX
307NXXXXXX
308NXXXXXX
309NXXXXXX
310NXXXXXX
312NXXXXXX
313NXXXXXX
314NXXXXXX
315NXXXXXX
316NXXXXXX
317NXXXXXX
318NXXXXXX
319NXXXXXX
320NXXXXXX
321NXXXXXX
323NXXXXXX
325NXXXXXX
330NXXXXXX
331NXXXXXX
334NXXXXXX
336NXXXXXX
337NXXXXXX
339NXXXXXX
347NXXXXXX
351NXXXXXX
352NXXXXXX
360NXXXXXX
361NXXXXXX
364NXXXXXX
385NXXXXXX
386NXXXXXX
401NXXXXXX
402NXXXXXX
404NXXXXXX
405NXXXXXX
406NXXXXXX
407NXXXXXX
408NXXXXXX
409NXXXXXX
410NXXXXXX
412NXXXXXX
413NXXXXXX
414NXXXXXX
415NXXXXXX
417NXXXXXX
419NXXXXXX
423NXXXXXX
424NXXXXXX
425NXXXXXX
430NXXXXXX
432NXXXXXX
434NXXXXXX
435NXXXXXX
440NXXXXXX
442NXXXXXX
443NXXXXXX
458NXXXXXX
469NXXXXXX
470NXXXXXX
478NXXXXXX
479NXXXXXX
480NXXXXXX
484NXXXXXX
501NXXXXXX
502NXXXXXX
503NXXXXXX
504NXXXXXX
505NXXXXXX
507NXXXXXX
508NXXXXXX
509NXXXXXX
510NXXXXXX
512NXXXXXX
513NXXXXXX
515NXXXXXX
516NXXXXXX
517NXXXXXX
518NXXXXXX
520NXXXXXX
530NXXXXXX
534NXXXXXX
540NXXXXXX
541NXXXXXX
551NXXXXXX
559NXXXXXX
561NXXXXXX
562NXXXXXX
563NXXXXXX
567NXXXXXX
570NXXXXXX
571NXXXXXX
573NXXXXXX
574NXXXXXX
575NXXXXXX
580NXXXXXX
585NXXXXXX
586NXXXXXX
601NXXXXXX
602NXXXXXX
603NXXXXXX
605NXXXXXX
606NXXXXXX
607NXXXXXX
608NXXXXXX
609NXXXXXX
610NXXXXXX
612NXXXXXX
614NXXXXXX
615NXXXXXX
616NXXXXXX
617NXXXXXX
618NXXXXXX
619NXXXXXX
620NXXXXXX
623NXXXXXX
626NXXXXXX
630NXXXXXX
631NXXXXXX
636NXXXXXX
641NXXXXXX
646NXXXXXX
650NXXXXXX
651NXXXXXX
657NXXXXXX
660NXXXXXX
661NXXXXXX
662NXXXXXX
678NXXXXXX
681NXXXXXX
682NXXXXXX
701NXXXXXX
702NXXXXXX
703NXXXXXX
704NXXXXXX
706NXXXXXX
707NXXXXXX
708NXXXXXX
712NXXXXXX
713NXXXXXX
714NXXXXXX
715NXXXXXX
716NXXXXXX
717NXXXXXX
718NXXXXXX
719NXXXXXX
720NXXXXXX
724NXXXXXX
727NXXXXXX
731NXXXXXX
732NXXXXXX
734NXXXXXX
740NXXXXXX
747NXXXXXX
754NXXXXXX
757NXXXXXX
760NXXXXXX
762NXXXXXX
763NXXXXXX
765NXXXXXX
769NXXXXXX
770NXXXXXX
772NXXXXXX
773NXXXXXX
774NXXXXXX
775NXXXXXX
779NXXXXXX
781NXXXXXX
785NXXXXXX
786NXXXXXX
801NXXXXXX
802NXXXXXX
803NXXXXXX
804NXXXXXX
805NXXXXXX
806NXXXXXX
808NXXXXXX
810NXXXXXX
812NXXXXXX
813NXXXXXX
814NXXXXXX
815NXXXXXX
816NXXXXXX
817NXXXXXX
818NXXXXXX
828NXXXXXX
830NXXXXXX
831NXXXXXX
832NXXXXXX
843NXXXXXX
845NXXXXXX
847NXXXXXX
848NXXXXXX
850NXXXXXX
856NXXXXXX
857NXXXXXX
858NXXXXXX
859NXXXXXX
860NXXXXXX
862NXXXXXX
863NXXXXXX
864NXXXXXX
865NXXXXXX
870NXXXXXX
878NXXXXXX
901NXXXXXX
903NXXXXXX
904NXXXXXX
906NXXXXXX
907NXXXXXX
908NXXXXXX
909NXXXXXX
910NXXXXXX
912NXXXXXX
913NXXXXXX
914NXXXXXX
915NXXXXXX
916NXXXXXX
917NXXXXXX
918NXXXXXX
919NXXXXXX
920NXXXXXX
925NXXXXXX
928NXXXXXX
931NXXXXXX
936NXXXXXX
937NXXXXXX
940NXXXXXX
941NXXXXXX
947NXXXXXX
949NXXXXXX
951NXXXXXX
952NXXXXXX
954NXXXXXX
956NXXXXXX
970NXXXXXX
971NXXXXXX
972NXXXXXX
973NXXXXXX
978NXXXXXX
979NXXXXXX
980NXXXXXX
985NXXXXXX
989NXXXXXX
In another route I have a pattern for every Canadian area code, expressed as 10 or 11 digits (this one has a different set of usable trunks). It looks like this:
1204NXXXXXX
1226NXXXXXX
1250NXXXXXX
1289NXXXXXX
1306NXXXXXX
1343NXXXXXX
1403NXXXXXX
1416NXXXXXX
1418NXXXXXX
1438NXXXXXX
1450NXXXXXX
1506NXXXXXX
1514NXXXXXX
1519NXXXXXX
1581NXXXXXX
1587NXXXXXX
1604NXXXXXX
1613NXXXXXX
1647NXXXXXX
1705NXXXXXX
1709NXXXXXX
1778NXXXXXX
1780NXXXXXX
1807NXXXXXX
1819NXXXXXX
1867NXXXXXX
1902NXXXXXX
1905NXXXXXX
204NXXXXXX
226NXXXXXX
250NXXXXXX
289NXXXXXX
306NXXXXXX
343NXXXXXX
403NXXXXXX
416NXXXXXX
418NXXXXXX
438NXXXXXX
450NXXXXXX
506NXXXXXX
514NXXXXXX
519NXXXXXX
581NXXXXXX
587NXXXXXX
604NXXXXXX
613NXXXXXX
647NXXXXXX
705NXXXXXX
709NXXXXXX
778NXXXXXX
780NXXXXXX
807NXXXXXX
819NXXXXXX
867NXXXXXX
902NXXXXXX
905NXXXXXX
And, I also have a route (actually a block, since the only trunk it selects is ENUM) for countries in the Caribbean that we would never call, in part due to the phone scams that originate from there (e.g. where you are left a message with a callback number in that area, and if you actually call it back you get charged some outrageous per-minute charge). Also some "special", potentially costly area codes (e.g. 700 and 900) are blocked here. It looks like this:
1242XXXXXXX
1246XXXXXXX
1264XXXXXXX
1268XXXXXXX
1284XXXXXXX
1340XXXXXXX
1345XXXXXXX
1441XXXXXXX
1456XXXXXXX
1473XXXXXXX
1500XXXXXXX
1600XXXXXXX
1649XXXXXXX
1664XXXXXXX
1670XXXXXXX
1671XXXXXXX
1700XXXXXXX
1709XXXXXXX
1710XXXXXXX
1758XXXXXXX
1767XXXXXXX
1784XXXXXXX
1787XXXXXXX
1809XXXXXXX
1829XXXXXXX
1867XXXXXXX
1868XXXXXXX
1869XXXXXXX
1876XXXXXXX
1880XXXXXXX
1900XXXXXXX
1939XXXXXXX
1NXX976XXXX
242XXXXXXX
246XXXXXXX
264XXXXXXX
268XXXXXXX
284XXXXXXX
340XXXXXXX
345XXXXXXX
441XXXXXXX
456XXXXXXX
473XXXXXXX
500XXXXXXX
600XXXXXXX
649XXXXXXX
664XXXXXXX
670XXXXXXX
671XXXXXXX
700XXXXXXX
709XXXXXXX
710XXXXXXX
758XXXXXXX
767XXXXXXX
784XXXXXXX
787XXXXXXX
809XXXXXXX
829XXXXXXX
867XXXXXXX
868XXXXXXX
869XXXXXXX
876XXXXXXX
880XXXXXXX
900XXXXXXX
939XXXXXXX
NXX976XXXX
Now, if you think that this was a much too long message to read, how do you suppose someone would feel about having to enter every single one of those lines individually? So I hope you are not saying that we would have to do that if we upgrade to 2.8 or later, because if that is the case, I absolutely, positively guarantee you that no version of FreePBX greater than 2.7 will ever be on one of our systems, until and unless someone figures out a way to avoid the manual entry.
Just in case I'm totally misinterpreting what I'm reading, that's all I'll say for now. Don't want to be one of those people who jumps to conclusions and gets all into a lather over nothing!
sir_sip, you are welcome to
sir_sip,
you are welcome to use which ever version of FreePBX you care to use, no one will stop you.
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
I got same problem. I just
I got same problem.
I just updated my freepbx to 2.8 on new installation and I wondering how to enter all my cellular prefix in outbound routes.
Will be very time consuming to do it one by one comparing to before that was just a copy and paste.
Will be good to have an option for entering in text area as before. Some button for create or import from text area.
Thanks in advance.
That response reminds me of
That response reminds me of the old Lily Tomlin operator character:
"We don't care,
We don't have to.
We're the telephone company!"
Sounds Like A Good Case For An Add-On Module
Maybe the folks who wrote the Bulk DID and Bulk Extensions module can craft an add-on module to load in a spreadsheet of routing info. I'm sure this won't be tough for experienced Asterisk/FreePBX guys to craft.
I remember on my Avaya systems, I had to enter each area code (and in some instances area code plus NNX) in the routing tables manually. It was a pain until someone came out with administration software that let me upload tables into the system.
FreePBX 2.8 is new. As more people use it, I'm sure new modules will be written to ease us into the changes.
I am already on it, I have
I am already on it, I have the module so far to erase route patterns and soon it will be able to add new patterns.
Stay tuned for Bulk Routes in the Contributed Modules repository.
Mikael Carlsson
(I am off-line, tinkering with my Chevy and my radios, don't know when I will be back)
Way to go, Mikael!
That was fast! Can't wait to see it!
Well, I might drop the whole
Well, I might drop the whole thing and maybe do it another way, but time will tell, it will not be for a couple of weeks as I have a lot of other things to do at work, remember, I only do this on my (limited) spare time.
If something is released it will only work for 2.8.
Mikael Carlsson
(I am off-line, tinkering with my Chevy and my radios, don't know when I will be back)
I really like the new format
I really like the new format and the ease of using it but I use custom contexts to separate routing for groups of extensions. A Clone Route button when adding a new route would go a long way towards resolving the problem when routes are on the same box.
Not withstanding this I look forward to your contribution Mike, it is quite painful and time consuming to make dozens of routing entries for a route which is not always on the same box.
stonet, why don't you add a
stonet,
why don't you add a feature request for a clone route button so the idea does not get lost.
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
My 2 cents
Our company has about 15 systems now running freepbx on asterisk 1.4. I'm one of the people that like to stay on the bleeding edge, well maybe not bleeding, but cutting edge. I had read some good and bad things about 2.8 but I thought with this one new system that I was setting up that I would try 2.8. The system would not be a critical system for about 2 months so I could easily switch if needed.
I have to say it is not really that bad. Yea, I did like the cut and past it was handy for some of the odd stuff we do to accomplish least cost routing. Also, I find that loading a route with a bunch of numbers in it takes a bit long to load. I don't think that is my system and am still investigating it. But it does seem sluggish.
Anyways.. I did have to make a couple of hundred entries and was no way in hell going to type each one. This is the computer age, we don't type hundreds of lines of stuff. We cut and past. But that not being available I tried the other easy way. I added it to the database.. Most experienced users should be familiar with the back end database that is driving your system.
A quick ODBC connection, a simple query, and presto.. Hundreds of numbers added in seconds. Reload front end and your good to go.
I guess what I'm getting at, is there are always more than one way to skin cat, and if you are an experienced user you should know your system in and out. In fact with 2.8 there is sooooo much more that is driven by the back end database that it can make multiple system maintenance so easy.
Just my 2 cents.
Rob
Rob, you are right it is a
Rob,
you are right it is a pain if you have to put a lot of entries in. There are some efforts looking into other options.
One approach, which has had some work done on an addon module, is to put a textarea back in, though the current module only allows for the match pattern, none of the others.
Another option that is being investigated is to allow for a CSV file to be loaded with all 4 fields. The assumption is that there are two classes of use cases out there. One class uses relatively 'simple' routing and does not have an issue with the current GUI. Another less frequent class has a lot of patterns because of some sophisticated lcr routing. A text area seems sub-optimal for something like that vs. a CSV file which would allow easy maintenance of the patterns in a spreadsheet.
My current thoughts are the CSV is probably more useful. Then the question is, does it get put in as an option in the routing (and trunk) modules. Is it done in another module that needs to be installed (which could still hook into the current page)?
Taking it a step further, would it be better to have a completely independent module which presented you with all your routes (or trunks) letting you check which ones should be acted on, and then let you upload a csv file and change all of the routes/trunks checked (with the option of either appending or replacing?) This latter mode may be more valuable for trunks and less so for routes, since it is more likely that trunks may have the same patterns repeated...
anyhow ... those are some of the thoughts that are floating around and being looked at. One more possibility that comes to my mind is to extend the idea of the current XML service in the wizard that is US-centric allowing the user to specify their own URL where it should fetch the requested patterns and thus allowing someone to manage their own source of patterns based on some input...
anyhow - just some thoughts as to what is being tossed around...
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
Hi, I think that a button
Hi,
I think that a button inside the module for showing the text area input as before for entering patterns will be good enough.
Until now, this is my only concern for updating my systems to 2.8. We use many patterns in routes for LCR.
With text area is easy to search, replace, copy and paste.
2.8 is wonderful, maybe a will use Rob advice for updating directly on database if we decide to upgrade for using new features.
Have a look at #4445
Have a look at #4445 concerning an option to upload a csv file from the dial pattern wizard select box.
r10159 in the 2.9 module branch is the suggested patch. If this tests out (needs some people to try it) and is a good solution we can look at back porting it to 2.8.
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
CSV file sounds like a great
CSV file sounds like a great solution - it would be very easy to convert existing lists of patterns into CSV format, and once in that format, it would be easy to work with them using either a CSV editor or a plain old text editor.
As for R_Henry's suggestion, unfortunately not everyone who runs FreePBX knows all the internal workings. What is a "quick ODBC connection"? That's not something users had to know to use with 2.7 and earlier. I like the CSV file idea much better!
I also hate the new format
I also hate the new format and would prefer to get the text area back. I don't think it makes sense to introduce a csv import or text entry add-on module to fix a data entry option that worked perfectly fine in the past. If users had trouble understanding how to use the text entry box then maybe someone should have expanded the help area instead of rewriting the entire code and then forcing users to look for alternate solutions to circumvent this change.
I know you meant well with the new data entry option but for those of us that only enter 1-2 routes it makes no difference if the y use the text box or new pattern boxes. However for those of us that use 100-500 routing entries it makes a huge difference.
I invite more user comments.
I invite more user comments. The more people complain the greater the chance of reverting this change.
if you are going to manage
if you are going to manage hundreds of routes, why wouldn't you want to maintain that in something like a spreadsheet.
In all the scenarios that I have seen where users were maintaining hundreds of routes, they were having to 'maintain' it as changes are constant in the telecom space with changes in local calling areas, new areas codes popping up, etc.
Maintaining such a list lends itself very well to a spreadsheet, especially if you are going to start to take advantage of prefixes, prepending and/or CID fields that can be done in the route (or trunk).
Also note, in the above discussions, the change was also put in place to add additional functionality which was problematic with the textarea, it wasn't no 100% just to change it, though simplification was one of the goals as this is one of the most confusing parts of FreePBX configuration.
I will also mention that I've seen a lot of positive feedback in this improvement from various places, a lot more then the handful of concerns that have been (legitimately) brought up wrt to managing large lists of routes/patterns. (Though, the CSV file addresses most of that and was why it was introduced).
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
I'll take the csv file
I'll take the csv file import option if there is no other choice and we need the added functionality. Personally I still like the text option best. Just because it's text does not mean I can't manipulate the data in a spreadsheet.
To use the csv import option we'd also need a csv export option and a way to clear the data before importing the csv file. When would this option be available in 2.8?
yes it does need a way to
yes it does need a way to clear the data and I believe there is a ticket open for that.
The CSV option is available in the 2.9 branch but you can manually load core on your system from there to check it out.
The bottom line, there was a lot of noise about this from a few people when 2.8 first came out (even though it was pointed out clearly in the blog and had been in beta for months). There were some legitimate concerns expressed and thus I put together the CSV file proposal. However, there has been almost no feedback since then other than a couple individuals.
This needs to be tested and a bit more feedback before putting it into 2.8 since it is a new feature which is usually not done in the current release and thus we want to make sure to get the proper feedback as it will be impacting thousands of production systems when we push it out to 2.8.
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
My guess is people found
My guess is people found work arounds like importing to the SQL file directly instead of using the GUI so the hoopla quieted down. Most affected users are experienced with Free PBX and probably figured out a way to overcome the issue.
Has anyone tested the csv option? We need to give feedback to Philippe to get it installed in 2.8 and I may not be computer savy enough to test this.
I just uploaded and tested
I just uploaded and tested the csv import function on my 2.8 system. Seems to work just fine. I imported 200+ records, then cleared all and imported it again. Works great. Good compromise and easy to use. I simply took my textfile and replaced the + sign with two commas to generate the empty prefix field.
My Thought and the CSV file.
Philippe,
I think one of the reasons there hasn't been much noise on this recently is lack of adoption of 2.8 because of this. Most of the folks that I know in this industry have not moved to 2.8, even though we all want the improved directory features. I personally feel that removing the textarea from the outbound route and trunk pages was a large mistake, no matter how hard maintaining the code base is.
That being said, I will take some time this weekend and look at the CSV option. After that I will attempt to modify my web page that creates routes for FreePBX to create that file. I will post back here when I am done.
John Mullinix, Cohutta.Com, Inc.
1-706-632-3343 -- sip://17066323343@qth.cohutta.org
Looking for Dundi peers in Baltimore, MD and Lake Wales, FL USA
Perhaps there are a lot of
Perhaps there are a lot of people out there like me, I am not a developer and in many cases I will find out about a change when I update or upgrade to a new version. I second the opinion from jmullinix on moving to 2.8, it just made my job harder, (at least for now). I have many other things and little time to check the many forums for new development and new ideas in beta, my fault I guess but a reason why not many comments on the issue.
To me it is way faster to cut and paste then messing with csv, spread sheets, import/export processes.
No rant here, just 2 cents.
Honestly, I was all negative
Honestly, I was all negative about the new "outbound route and trunk pages" UNTIL I TRIED the CSV import option. It took may 2 minutes to copy/paste the routes from version 2.8 into notepad, replace the + sign with two ,, and import the csv file back into version 2.8. It is definitely a viable option.
Alas there is a bug in the "outbound routes page". There is no "clear all fields" button like in the "trunk routes page". It also needs a CSV export option to retrieve the data from freepbx.
the clear all field is
the clear all field is needed and if I'm not mistaken there is an open ticket already for that to get done (plus your comment added to the other ticket).
As far as the export option, I'm not sure if that is really needed. It is clearly helpful if you have an existing route that you migrated and need to export to edit.
I would expect most users who who manage a long list of routes to do so in a separate document/spreadsheet however we'll have a look at how much more is involved to do the export vs. the import that is already there.
John, your feedkback is appreciated. Having checked the adoption rate of 2.8 though, it doesn't appear to show and significantly different trend to that of other new releases.
I understand your feedback wrt to the textarea being easier (I had always though the same and still do, being an advanced user of course). However, as I first mentioned, it created some limitations and going to the new GUI made it much more reasonable to add the new ability such as the prefix. Furthermore, having seen many many users struggle through outbound routes and trunks (which are still not obvious), it was only getting more complicated if we were to try and add more capabilities with more cryptic notations.
From the hundreds (maybe thousands?) of systems that I have seen, it is actually fairly un-common to have complicated route and trunk patterns to begin with. And probably most often when such ones are encountered, they were simply users who took advantage of the XML service built into the wizard.
This isn't to say that the legitimate use of long lists of dialpatterns is not present nor is it to discount that list, which is why for now we put in the CSV option to be reviewed and potentially back-ported. There has been a partial attempt to provide the textbox functionality by a small module written and available in the contributed_modules repository that will allow a textarea to be used to input initial patterns. However, that is currently incomplete in as far as, to the best of my recollection, it only addresses the 'match_pattern' and does not provide a means to deal with the prepend, prefix or cid options. However, this may be adequate for some and is clearly available to be expanded upon if someone wants to do that on the Module. It is of my opinion, give what I have seen in the hundreds of systems that I have observed, that that the need for an 'advanced' ability to continue to use something like the textarea is better provided as an optional add-on vs. the default (which is now the GUI). As such, I believe if there is a demand for that, it is best to further develop the module that Andy started if the existing functionality is in-adequate. (Note, it would also be possible to further modify that module to have it remove the default GUI completely when installed, vs. simply adding the textarea in addition to the GUI).
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
Some noise from the
Some noise from the background....
2.8 has a major feature for multi-site systems, the ability to use trunks as a target of a route. It has been a God send for us.
So the first time I had to load the "loop around" internal route with 400 DID's I groaned. Bottom line was 20 minutes of looking at the tables and I was able to use PHPMySQLAdmin to take care load a CSV.
I welcome the addition to any solution within the envelope of FreePBX.
Tutorial
Topic discussed greatly here but there is no real how to so
nice tutorial at http://michigantelephone.wordpress.com/2011/02/27/how-to-export-outbound...
also in my case nothing helps as THERE IS NO upload CVS options under dial pattern wizard -((
Is there a way round it?
There is no need to follow
There is no need to follow that article, it is incorporated in 2.9.
There is a patch for 2.8 in ticket 4691, but there was no feedback on it so it was closed as wontfix.
If you feel like to test this out and give constructive feedback you are more than welcome to do so,
Mikael Carlsson
(I am off-line, tinkering with my Chevy and my radios, don't know when I will be back)
feedback
Yes I am happy to do it and can tell you that it is working well.
Unfortunately I disagree there is need as THERE IS NO instruction how to do it.
As well as not every one using 2.9 actually with very simple user interface I think more and more people decide not too use it.
This has been a show stopper
This has been a show stopper here since 2.8 update. how unfortunate this was changed, even with the import from csv it is a headache to say the least, but I guess not too many voices in favor of the old ways. still running old version in my 10 boxes. :(
I suspect there would be
I suspect there would be many more voices in favor of "the old ways" if anyone really thought it would do one bit of good. Most people simply will not bother to compose a message just to post their dislike of the new way, but that doesn't automatically mean that they prefer the change.
As for the patch for 2.8, I would have been happy to test it, but I had already replaced the two affected files with their equivalents from the 2.9 version and didn't save the originals, so I had nothing to patch. I still think they should backport the ability to upload .csv files to 2.8, but I guess they are looking ahead to 2.9 now.
sergiocesar, this topic has
sergiocesar,
this topic has been brought up on multiple occasions and not just in this forum, looking for people to test the patch on previous releases and other discussions, without any takers.
As it turns out, there were a very few vocal people who had an issue but didn't even jump in to help test fixes for earlier releases. Keep in mind that there are tens of thousands (actually hundreds of thousands) of users of the system out there, and 99.999% of those are not very publicly vocal. The fact of the matter is that the GUI has been very well received and for the very very small minority of systems out there that are managing large numbers of patterns, the CSV upload has proven quite a reasonable solution as it also allows the patterns to be maintained in a spreadsheet since many instances of such large sets require ongoing maintenance as numbers need to be added or removed.
In any event, the earlier releases are not going anywhere and will be available and maintained for security issues for quite some time to come if that is your preference.
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
For those that use FreePBX
For those that use FreePBX 2.8 or 2.9 and are still struggling with this new way of entering routes and patterns, I just came across this thread in the PBX in a Flash forum that seems like the answer to this:
FreePBX Swiss Army Knife Module