2.8 dial pattern and rules

I invite more user comments. The more people complain the greater the chance of reverting this change.

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).

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 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.

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 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.

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.

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 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 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).

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.

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-route-dial-patterns-and-trunk-dialed-number-manipulation-rules-to-a-csv-file-in-freepbx/
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 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,

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 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. :frowning:

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.

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.

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