WARNING about FreePBX 2.8

[tm1000]

As I said I would, I created a module that allows one to enter bulk dial patterns. Exactly like the old way into 2.8

http://pbxinaflash.com/community/threads/missing-bulk-dial-patterns-in-freepbx-2-8.7677/

 

[wardmundy]

 

[Baylink]

And of course, this leaves us *precisely* where we were:

That was so much labor that PL couldn't justify putting it in himself? Particularly in light of the vocal opposition to not having it?

Thanks, BTW, tm.

 

[tm1000]

And of course, this leaves us *precisely* where we were:

That was so much labor that PL couldn't justify putting it in himself? Particularly in light of the vocal opposition to not having it?

Thanks, BTW, tm.

It wasn't a lot of labor (2 hours-ish) however it's not very pretty and would confuse a new or unexperienced user the way it's written now.

It's too bad because I don't think there's anyway for me to disable the new dial plan section, if I could do that then this would be the perfect module. But it does what it's suppose to do.

 

[p_lindheimer]

Look a little closer

And of course, this leaves us *precisely* where we were:

That was so much labor that PL couldn't justify putting it in himself? Particularly in light of the vocal opposition to not having it?

Thanks, BTW, tm.

BAYLINK,

don't be so quick to judge.

Have a closer look at what Andrew put up. I suspect he will be the first to tell you that the textarea he put there is very limited and doesn't do at all what the pre 2.7 textarea does.

The only thing it does if you have a look at the code that he checked in was to fill in the match_pattern. It will not handle prefixes, prepending or callerid fields. There is a lot more parsing to handle those plus the fact that prepending was never handled.

As has been indicated on that thread, there are developers looking at option given some of the feedback.

You may also want to consider your definition of 'vocal.' It's easy for one or two people to be 'vocal.' on any forum. With well over 3000 2.8 systems running at this point, a couple of people being 'vocal' has very little meaning. (And even with that - there are still developers look at options to handle bulk loading with full functionality...)

 

[tm1000]

BAYLINK,

don't be so quick to judge.

Have a closer look at what Andrew put up. I suspect he will be the first to tell you that the textarea he put there is very limited and doesn't do at all what the pre 2.7 textarea does.

The only thing it does if you have a look at the code that he checked in was to fill in the match_pattern. It will not handle prefixes, prepending or callerid fields. There is a lot more parsing to handle those plus the fact that prepending was never handled.

As has been indicated on that thread, there are developers looking at option given some of the feedback.

You may also want to consider your definition of 'vocal.' It's easy for one or two people to be 'vocal.' on any forum. With well over 3000 2.8 systems running at this point, a couple of people being 'vocal' has very little meaning. (And even with that - there are still developers look at options to handle bulk loading with full functionality...)

Yes it's just a simple textbox and it doesn't parse anything it just adds to the database.

In fact I even hijack the _POST variables to trick the new dial plan function into writing to the database.

However if someone installed a system with 2.8 and they had a huge list of Dial Patterns and didn't want to enter it one-by-one then this would appease them for now. Thats all I wrote it for was a solution for the meantime.

 

[p_lindheimer]

For now I'm going to hold my enthusiasm in check, since it looks like Micke Carlsson is already hedging a bit on what he'd written earlier:

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

None of that sounds like he's really committed to making that module happen, but it's that last sentence that has me most concerned.

Given all your comments it seems you really like to read into things. Why not just ask him what he meant (or me) back on the forum thread where it happened.

I think if you ask him what he means by "...only work for 2.8" it would imply that any 'bulkupload of CSV' patterns would not be supported on earlier releases (vs. future releases). You may also want to consider that his comments about doing it another way don't mean not doing it and that maybe there has been discussions amongst developers as to better ways vs. an external module that this may be done just like there are already wizards that have been available for years and were kept in 2.8 that will pull these same patterns from other sources such as web services.

heck, I even recall seeing some of Ward's early posts, where he'd included trunk dial rules that didn't do a thing because they didn't add or remove any digits

I can't comment on what Ward did not having looked at his post, but there are very valid reasons why one might have a dialpattern in a trunk that does not do any specific manipulation (e.g. doesn't add digits or strip digits). It still does something and I can provide a set of rules where functionality would break if this was not done. As I have said elsewhere, this whole space of routes and trunks with the dialrules and dialpatterns is one of the most hard to understand parts of FreePBX, and not just for newbies...

 

[Lost Trunk]

Given all your comments it seems you really like to read into things. Why not just ask him what he meant (or me) back on the forum thread where it happened.

Perhaps because you guys at least initially seemed not to care what you have inflicted on users, and I have no desire to get into an argument with you on your playground. All I was going by was what was written - if someone doesn't want their words misinterpreted, maybe they should write more clearly.

I can't comment on what Ward did not having looked at his post, but there are very valid reasons why one might have a dialpattern in a trunk that does not do any specific manipulation (e.g. doesn't add digits or strip digits). It still does something and I can provide a set of rules where functionality would break if this was not done. As I have said elsewhere, this whole space of routes and trunks with the dialrules and dialpatterns is one of the most hard to understand parts of FreePBX, and not just for newbies...

I am aware that in certain circumstances trunk dial patterns can have other uses (for example, serving as an "exception" to subsequent rules) but in some of the very early examples it was just a matter of putting things in trunk dial patterns that had no effect whatsoever. I think we probably have all made that mistake early on. But just because new users sometimes have difficulty coming up to speed on how these work is not a good reason to make a major functionality change that will make things much more difficult for experienced and knowledgeable users.

I do find it interesting that you did not come over to comment on this thread until someone actually offered a fix, of which you apparently don't fully approve. This just reinforces my belief that you and the current development team have some "control freak" tendencies. You may not care what users want or how much your are inconveniencing your existing users, but let someone else come along with a fix for your mess and here you come to point out that it's not perfect. Did it ever occur to you to run a major change like this by your users before you just went ahead and implemented it? No, you just imposed it. Had you checked with your users beforehand, you might have discovered that this was going to be an issue for some.

So I would suggest it's bad form for you to come around and throw darts at those that are at least trying to be responsive to the needs of existing users. You may think there is nothing wrong with breaking existing functionality, but some of your users apparently strongly disagree! And tm1000's fix is available now, unlike the fix that Micke Carlsson might or might not get around to releasing.

 

[jroper]

Did it ever occur to you to run a major change like this by your users before you just went ahead and implemented it? No, you just imposed it. Had you checked with your users beforehand, you might have discovered that this was going to be an issue for some.

Be fair, he did. We've had since at least March 21st 2010 to comment on these changes when the first beta was announced.


Joe

 

[wardmundy]

Keeping It Real

I don't have a dog in this fight, but...

Even after being made aware of the serious problem this would cause for many system integrators, the problem was not addressed in the actual FreePBX code. In fact, 2.8 just left beta status if memory serves me correctly.

BOTTOM LINE:

Progress and civility are both good things. Throwing the baby out with the bathwater, not so much.

 

[Lost Trunk]

Be fair, he did. We've had since at least March 21st 2010 to comment on these changes when the first beta was announced.


Joe

Well, I didn't see that post, though given the date, it's perfectly understandable in my case (on the date of that post I had a considerably more important family-related matter to deal with). If that was the only place that information was posted, I can see how some of us may have missed it. A change that big at least deserved its own post, not just a mention "below the fold" on a post that covered many changes. And then there is the way the change is introduced:

"Moving on to Outbound Routes and Trunks. While working on the internal plumbing I decided to get rid of those dialrule textareas in favor of a GUI that might make it more intuitive and less error prone. ..."

I bolded those two words up there just to make the point that even if someone might have seen this post, they may have thought that it was already a done deal. The post certainly doesn't invite comment or criticism, so if this was the first mention of this change, there were probably many people who read it, didn't give it that much thought because they were not being asked to comment on it, and only after they had finally installed it on their systems did they have that moment of realization, that sinking feeling of "holy sh-t, you mean I have to enter each and every one of these several hundred lines of dial patterns in these little text boxes?!?!"

And note that PL says "I decided" - not "I asked the community what they thought and then after careful consideration made this major change", not even "I consulted with all the other developers and we all agreed this was the way to go" (though now that someone has brought it up, he'll probably say all the developers were in agreement on this change), but simply that he decided to impose this change on everyone.

So, my original comment might still be valid. I give you that he did give some notice, if you happened to see it buried in that post, of what his intentions were, but there's still no indication that he fully explained the impact of this change, nor sought opinion from the community at large (nor anyone other than himself) prior to implementing this.

 

[dswartz]

Valid points, trunk. Also, as someone who has been in the SW business for many years, if the company I work at made a change that broke existing customer code with no way to work around it, there would be hell to pay. And saying "well don't upgrade, you are free to use older releases" doesn't really cut it.

 

[jroper]

Hi

...I work at made a change that broke existing customer code....

I don't think it does break anything, it's just different. All your existing plans will be upgraded.

I think that a misquote from Phineas T Barnum is called for:-

You can satisfy some of the people all of the time, and all of the people some of the time, but you cannot satisfy all of the people all of the time

Some will be happy with the reduced complexity, some will not be, but being open source software, you have a variety of options open to you which would not be available if this were proprietary closed source software. e.g.

• Reasoned argument - I would avoid personal comments and base the arguments around the benefits of your proposal. The personal comments tend to overshadow the valid technical points made, and are therefore lost in the noise, and you achieve nothing.
• Develop a module - which appears to be done in part which may do what you require.
• Put forward a bounty - as per custom contexts.
• Fork - as per Trixbox, but I could not recommend that for a whole host of reasons.

I for one appreciate PL's strong leadership, and his ability to motivate and direct mostly unpaid and voluntary developers, without this, I do not believe we would have the class product we have today!

Lost Trunk, I would put this down to "school fees", take a deep breath, and start again with one of the above options.



Joe

 

[p_lindheimer]

I do find it interesting that you did not come over to comment on this thread until someone actually offered a fix, of which you apparently don't fully approve. This just reinforces my belief that you and the current development team have some "control freak" tendencies. You may not care what users want or how much your are inconveniencing your existing users, but let someone else come along with a fix for your mess and here you come to point out that it's not perfect. Did it ever occur to you to run a major change like this by your users before you just went ahead and implemented it? No, you just imposed it. Had you checked with your users beforehand, you might have discovered that this was going to be an issue for some.

I don't regularly follow the forums here. I commented on this post when Ward emailed me making me aware of it. I'm sorry if that hurts your "conspiracy" theory again and further wrecks your ability to twist everything into some sort "holy war." Unfortunately for you, I really don't think that is why people come here.

As far as running things by users, I can only ask you what you are smoking? All the changes have been run though thousands of users, what do you think a beta program is about. There were even tickets filed against aspects of these changes that were addressed

But just because new users sometimes have difficulty coming up to speed on how these work is not a good reason to make a major functionality change that will make things much more difficult for experienced and knowledgeable users.

It's not just new users which is one of the points, and the changes, as mentioned, also allow for new functionality like the prepend field and manipulation of the '+' digit in trunks which was not previously possible. I've also heard from plenty of experienced users that the new format makes it much easier and less error prone for the vast majority of typical use cases. And as mentioned, even though this issue was brought up in the 11th hour (really in the 13th hour) after being available for reveiw for months, and exposed on the primary blog (not some random forum post) there are a couple of angles being looked at that may help to address the occasional need of inserting a large number of route or trunk patterns.

So I would suggest it's bad form for you to come around and throw darts at those that are at least trying to be responsive to the needs of existing users. You may think there is nothing wrong with breaking existing functionality, but some of your users apparently strongly disagree! And tm1000's fix is available now, unlike the fix that Micke Carlsson might or might not get around to releasing.

Interesting mis-interpretation, especially since I'm the one who spent time with tm1000 to show him how to implement such a fix... There are no 'darts' being thrown, read tm1000's reply - the clarification was accurate and would save many an experienced users the headache of scratching their heads trying to figure out why the prefix patterns they put into that textarea keep getting ignored...

 

[dswartz]

Well, I see your point, yes. What I was getting at was that having something that has always worked a certain way suddenly stop working that way (especially with no known avoidance) was my only nit. I am happily using 2.7 and will probably upgrade to 2.8 when it gets a little more mileage out there. I am no longer living alone, so I now have to worry a bit more about WAF

 

[dswartz]

Joe, I agree with you. Going back and re-reading the entire thread, I think I may have put things too strongly, although it would have avoided the entire imbroglio to have the workaround available before making that change, but that's water under the bridge now.

 

[jroper]

I am no longer living alone, so I now have to worry a bit more about WAF

Oh dear, I am sorry to hear that, never make the mistake of being both right about something and male at the same time - otherwise you will be due for some deaf and dumb dinners ;-)

Joe

PS I picked that comment up at http://revk.www.me.uk/ it's worth a read just to see a real professional ranter at work, and relevant to IT, and telecoms.

 

[dswartz]

not to fear

Oh dear, I am sorry to hear that, never make the mistake of being both right about something and male at the same time - otherwise you will be due for some deaf and dumb dinners ;-)

Joe

PS I picked that comment up at http://revk.www.me.uk/ it's worth a read just to see a real professional ranter at work, and relevant to IT, and telecoms.

Not to fear, I have been married before, so I am aware that is is impossible to be right and male I will check out that rant, thanks

 

[jroper]

I have been married before

Aaah, the triumph of optimism over experience ;-)

 

[dswartz]

Yup, sure enough.