As FreePBX 2.7 Beta is being tested, we are seeing some issues with the Custom-Contexts module from the FreePBX Add-On’s repository.
This module was user provided and its original creator has left it in the public domain to be maintained.
The FreePBX folks would like to know if enough of us use or would use this module and be willing to pay a bounty to get it fixed and compliant with current and future releases. There are a few existing problems in the module and new ones that are emerging with FreePBX 2.7 Beta
For people who have not heard of the Custom-Contexts module, this module lets you set up separate contexts for your extensions which allow for customized routing based on the custom context you create. In my case, I suppot two locations in different parts of the country. I have one set of contexts for location A and another set of contexts for location B. This allows me to set up different routes for local calls, 911 calls and toll calls at each location. This is great if you don’t want separate boxes or virtual servers for each location. You can use it with your home and vacation home or on a campus wide application.
Custom-Contexts, one installed in FreePBX, modifies the extension record so you can use a drop-down menu to select the context you want the extension to be in. It is an elegant solution to a number of issues for multi-site installations on one call-server. This is not intended as a multi-tennant application; but merely as a handy way to customize outbound routing based on context of the extension.
I’d like feedback on whether people are willing to pay a bounty to get the module updated. If there is sufficient interest, we’ll get an estimate and post a bounty request. In addition, I’ll collect specifics from people who currently have issues with the module see if we can address future requirements. Please respond whether you:
- I use the module and will pay a bounty
- I use the module already but will not pay a bounty
- I would like to use the module and will pay a bounty to update it.
put me down as a #1. does anyone have any general idea of the bounty that will be needed yet?
I’d like to know if you have any current issues with the module and what they are. Once we get some idea of how many people are interested, if there are enough, we’ll get a programmer to look at the module and give us a quote. No idea until then. This is just a “feasibility” poll at this point.
i am using freepbx 184.108.40.206 and using custom contexts primarily for manipulating outbound routing. i have not experienced any problems at all so i am a bit in the “what’s the fuss about?” mode with my only awareness of issues being what i read in posts here. obviously reading that upgrading version can wipe things out is not something i want to encounter, so if a bounty is what it takes to keep this VERY handy module in the mix, count me in.
I have one problem with Custom Contexts. The bad-number context which inserts a 3-second dial delay when used with zap extensions as documented here:
is automatically regenerated by the custom contexts module even if the ampbadnumber setting is disabled, reintroducing the delay. I got round this by frigging with the code.
I would contribute towards updating this module.
Thanks fraggle4! This is good feedback. I had the same problem until I got rid of my Zap stuff but never got to the bottom of it. This is the kind of info I want to present to a prospective programmer to fix the module.
I use the Custom Context module and would be more than happy to contribute to moving it to the supported module status.
We have been down this road before and I thought the code was not in a condition to put it in the general release.
Do we have a level of effort estimate for this work?
the question being raised is not what it will take to move it to an officially supported module. What is being asked here is what current issues are there and who might be willing to contribute so that the contributed module can be updated to remove those issues.
Some reports have indicated that there are problems with it in 2.7 (and even earlier releases from what I am hearing here). If the problems persist, and are substantial in nature, then either someone needs to step up to address those problems or we will have to take it out of the Extended Repository. The reason for this is that the idea behind the Extended Repository is that:
- The Module should of interest to a reasonable portion of the Community
- The Module must work and be maintained
I told kenn10 that if he wants to assess and organize support to address current issues, that I would be glad to help assess what the cost would be and find a developer who would be able to address the issues. This is assuming that someone doesn’t want to contact naftali and see if he would provide the required fixes (assuming he is still around these days).
I’m using it with 2.6 and haven’t notice any problem.
Yes I would like to have it supported as it’s a great tool for multi tenant PBX or to easily limit some extensions (like lobby guest phone, or to ask for password after hours for international calls).
If it was to be improved, I’ve noticed many users having trouble to understand that the red ‘group’ settings are overriding the individual settings. A better GUI that would show what settings is impacted by it may make it more user friendly.
I use custom contexts. I find it really usefull except for a couple of things. Follow me doesn’t seem to follow the custom context and uses the default route and also when adding a new route I have had issues where certain users cannot call internally so I have to virtually redo all the contexts to get it working again.
Saying that I would be still be interested in contributing to a bounty.
I am willing to contribute.
I make heavy use of custom contexts in my dialplans and in testing my existing configuration with 2.7 I have found the only impact for me so far is that the outbound callerid was no longer being correctly set to the callerid in the extension settings. I found that this was due to the fact that the call to macro-user-callerid was removed from the individual outbound routes in 2.7 and included in the outbound-allroutes context which is not allowed in my custom contexts. I am not a programmer so my short term workaround was to add a call to the “user-callerid” macro in each custom context’s “custom” context, but if someone would run with this I would be interested in contributing to this modules modernization.
Bump to keep this near the top.
Yes I used in all of my installations and friends, also I advice it sometimes.
The modulo is used as a dialler rule to avoid international or phone calls to extensions that are not allowed to do.
I would pay a bounty to update it, but it should be a fair amount.
kenn10 (or someone):
can you see if this patch: #3994 fixes the select box issue brought up on these custom-context threads?
If so, we can get that into the custom-context module and at least address one of the issues on the list without a bounty:)
p.s. please comment on the ticket if it works, thanks.
I use it all the time it is a simple way of partitioning users on the same box so they can have there own outgoing trunks allocated to them and it is great for barring international and cell phone access, things that are most likely required more outside of the US than within. To date I have not met any serious problems using the module with various flavours of free pbx.
It needs a bit of cleaning up on the GUI to bring it up to expected free pbx standards and make its use much more self explanatory, for example it would be nice for the extension screen custom context name box to show the explanatory name allocated to the context rather than having to look in the context box above for the context name.
If it could become a supported module I would be happy to contribute towards the cost.
I’m out of town all week and will be unable to apply and test the patch. Can someone else please try this out and see if it fixes the issue on the Extensions screen?
I can try it on Wed. I am on client site until then.
Patch #3994 has corrected the issue with the selected custom-context not remaining on the Extensions screen once set. I’m running FreePBX 2.7 on Asterisk 220.127.116.11-rc2 and all is well with that patch.
Now we need to figure out what it will cost to get the other issues corrected so we can collect bounties.
can you ‘bounce’ that ticket up and put the feedback in there so it shows up on today’s radar and I will try to address it.
I also have a change in 2.7 coming that may compensate for the other bug in custom context (I may have already checked it in, can’t recall).
I’ll then ping naftali5 since I have not heard back from him in about a week to see where he is at.
On a separate note though, 2.8 will be guaranteed to completely break custom context severely (one of a few reasons why it was never added to the project supported set of modules). So getting it working for 2.8 is going to be a much bigger undertaking… so it’s not too early to start thinking about collecting a much bigger bounty if people are going to want this module to continue to live beyond 2.7.
That’s distressing about the module being completely broken for 2.8. Is there any hope of this becoming a core supported module?
I’m personally watching the FreePBX/FreeSwitch development in hopes of moving away from Asterisk altogether. Do you have any feedback on partitioning or custom routes as a function of FreeSwitch with FreePBX 3.0?