1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. If you had a PIAF Forum account in the vBulletin days, log in with your old credentials. Otherwise, sign up again and we'll get you back in business as soon as we can.
  3. A serious FreePBX vulnerability has been reported. Update your Framework Module immediately. Click here for details.

GOOD NEWS FreePBX Swiss Army Knife Module

Discussion in 'Add-On Install Instructions' started by tm1000, Jul 11, 2011.

  1. tm1000 Schmoozecom INC/FreePBX

    Version: 2.0
    Updated: 7-27-2011

    This is a simple module I created to help supplement some missing/requested features by users for FreePBX. Though I am an active developer for FreePBX this module is not supported by FreePBX

    Right now this module allows you to:
    • (NEW)Reg-Exp White/Black List
    • Export a CSV file of your Dial Patterns from your Outbound Dial Plans to use in importing into other Dial Plans on other machines or for your own personal use
    • Use Old Textbox Dial Patterns for Outbound Routes (all of the prefix(|), callerid(/) and prepends(+) work as you fondly remember them from the pre 2.8 days.)
    • A Modified Blacklist Module that allows you to enter any value not just numbers


    As time goes on I will add more requested features. Or you can request more here.

    All settings can be changed under Tools -> Swiss Army Knife!! -> Advanced Settings

    Note: You HAVE to go to the 'Blacklist (Modified)' module under tools under 'Swiss Army Knife!!' to add any value to blacklist. I did NOT modify the default Blacklist module and you will still have to have it enabled for the blacklist features to work. :)

    Download from Here: http://www.the159.com/sak/sak-latest.tgz
    Repo Here: https://github.com/tm1000/freepbx-swiss-army-knife (Feel Free to Fork and then submit Pull Requests)
  2. GREAT! Thx for the contribution....

  3. lgaetz Pundit

    Great news. Thanks a lot for this.

    1. I'm using FreePBX 2.8, Installed the module, enabled the two checkboxes under tools, SAK, Settings but I don't see any change under outbound routes/trunks. How do I access the pre 2.8 dial rules entry method?
    2. Going to Tools, SAK, blacklist, entering 'asterisk' in the Number/Name field and clicking submit results in this error: "The section you requested does not exist or you do not have access to it."
  4. tm1000 Schmoozecom INC/FreePBX

    I wrote this under FreePBX 2.9 so I'll check under a 2.8 distro right now

  5. Didn't attempt to change the entry method (yet, but I will!), but the CSV export works great under 2.8. I can, however, confirm the blacklist issue. I trust you'll be able to address the issues, so, thank you SO MUCH for this, this addresses some of my main concerns about recent versions of FreePBX!
  6. tm1000 Schmoozecom INC/FreePBX

    Ok all fixed now in 1.0.1


    lgaetz, I believe you didn't see the options because how I had the display setup was really confusing on certain systems depending on how FreePBX loaded other modules and in what order. I didn't notice that until I loaded it on another system. Should be much better now.

    The blacklist issue was an dumb error on my part that has now been fixed.
  7. lgaetz Pundit

    Confirmed, blacklist entry working as expected and the dialplan field is now available in Outbound Routes. I havn't done any actual testing yet but I found another minor issue tho. The existing FreePBX 2.8 dial plan rules got imported into the SAK without the prefix and prepend digits. Example, I have pre SAK rules that look like this:
    but SAK imports them as:
    Not a serious issue, I can manually go thru my rules and clean them up. The second rule edited properly, I was able to add the '902+' with no problem but when trying to edit the last rule to this:
    I hit submit and FreePBX always changes it to this:
  8. wardmundy Nerd Uno

    The Hostage Crisis is Over :)

  9. tm1000 Schmoozecom INC/FreePBX

    hmmmm. Yes, FreePBX actually strips your + and | out. I'll have to add some code in there to parse it but first I need to ask

    1. The numbers before the + are what? Prefix?
    2. The numbers before the | are what? Prepend?
    3. How would a number with Prefix & Prepend look?

  10. darmock PIAF Developer

    I wish to extend our thanks to tm1000! We really really really appreciate his hard work. His swiss army knife is just what was needed. We hope you continue to expand it.

    I must say it is nice when these little problems get fixed without having to write a book about why we need it etc etc....


  11. lgaetz Pundit

    Within FreePBX, Prepend adds leading digits so it is +, prefix subtracts leading digits so it is|

    I only think I know the answer to this one, so someone else please chime in here


    ps - I haven't tried the caller id field, but it will have to take the "xxx" digits in the caller id field and add them to the end of the dial rule like this "/_xxx"

    pps - this post have some good info provided it is accurate, I haven't tested.
  12. dward Guru

    I am not sure if this is how you want to handle this, but I've created a fork of your code on github and have submitted a pull request for some changes that adjust the display and parsing of numbers with prepend/prefix/callerid.
  13. tm1000, you are my hero! :biggrin5:

    Regarding the patterns, let me give you an example. Suppose I have a rule that looks like this:


    I might use this if I wanted to send international calls to a European carrier that requires an "00" prefix rather than "011", AND I wanted to restrict use of this route to extensions 200 through 299.

    Here is how it should be written into the text box:


    Note the underscore before the extension pattern. This gets a bit tricky because technically if it's a single extension rather than a pattern then the underscore should be omitted, such as:


    Naturally you only need to include the separators if the field is not empty. So If the first field is empty you don't need the +, if the second is empty you don't need the | and if the last is empty you don't need the /

    Note it is possible to have a "full replacement" rule with no third field at all. For example, let's say you had a user in Minnesota on extension 444 and when they dial 811 you want it to go to Gopher State One Call. So, in your "Toll Free" route (or a special route you have set up just for such translations), you might include a rule that looks like this:


    So if the user of extension 444 dials 811, it will translate it to 18002521166 before sending it to the trunk(s). This is a perfectly valid rule, even though there is "nothing" in the third field.

    Hope this helps!
  14. darmock PIAF Developer

    Wonderful of course the patch is only for the 2.9 tree. Where as the SAK works on 2.8 which is what the majority of our users have installed. I can't see forcing everybody to upgrade for a single feature enhancement.

    Of course PIAF now comes with a CLI version that does the same thing that the SAK does for blacklist. We won't attempt to duplicate the other features he has so graciously provided to us with a minimum of fuss. I thought you had left our forums good to see you back.

  15. That won't help us users of FreePBX 2.8, or FreePBX 2.9 users, unless you decide to backport (and since you guys still haven't backported CSV upload to 2.8, I'm not holding my breath).

    And, you outright refused to even consider giving us back the pre-2.8 method of entering dual patterns. So in my opinion this is a MUCH needed module. We need more developers like tm1000 and fewer likeā€¦ never mind, I'm not going there.
  16. Actually, unless I'm reading it wrong, it's only implemented in 2.10 (note where it says Milestone: 2.10). But maybe I'm wrong, their ticket system can be a bit confusing at times.
  17. lgaetz Pundit

    There is no harm in always having an underscore before the extension whether it is a pattern or explicit. My own experimentation back in the days of FreePBX 2.6 resulted in inconsistent behavior unless I always used the underscore in front of all extension patterns.

    Unless someone can point out the error of my ways:
    will always equal:
  18. lgaetz Pundit

    For this one case, where the rule is all prefix and prepend, can you place a period in the spot where the missing phone number would be. i.e:


    I think that might make it easier to code.

  19. tm1000 Schmoozecom INC/FreePBX

    Yes this is exactly how I wanted it done! It's why I love github! You don't have to be part of a project to help out. :)

    I'm assuming this will do the parsing correctly as stated by others above.

Share This Page