I would like to get a couple of bugs in the unsuported Custom Context Module 0.3.3 when in use with Trixbox 2.6.1 straightened out:
Bring up the context name in the Custom Context box when an extension’s details are edited. At the moment the box comes up blank even if a context has been added to the extension so you have no idea if a context is there or not. Ideally the box should show the default “Allow All” if no context is selected or the context name when a context has been added.
Get rid of the line 589 php warning that appears across the top of the module screen.
If anyone is interested please post contact details here and we can discuss the quantum of the bounty after ascertaining how much work needs to be done.
well if the newer version fixes it, I would suggest you arrange for the payment of the bounty you are offering after the fact. Probably 75% Naftali and 25% the FreePBX project since the last set of bugs Naftali posted fixes on the forum iirc but we incorporated them and have been maintaining it in the contributed_modules directory even though it is not an officially sanctioned module. If there are other things you are looking for, naftali would probably be the best bet as mentioned. (he is the original author).
The new version has fixed the php bug, the other thing is not really a bug but an annoyance, I guess it would be relatively easy to write something in the Custom Context box as the actual context does appear in the context field so a bit of manipulation when writing the screen is all that is required. I will certainly contribute if that can be done.
I have not been able to actively participate in any FreePbx work lately due to work responsibilities. I only had time while my office needed what i was doing.
That said, I do not want my work to evaporate as there are still many people who keep me abreast with the news and the overall public requirement for these features. (Thanks lazytt for bringing this post to my attention.)
If there is any work needed to keep the module alive - or improvements which are agreed to be worth the effort, I can try to make time for it.
Lastly, and most importantly, I would like to publicly thank phillipe for keeping freepbx alive (and kicking!) through what i know was a hard time (rob leaving, etc.) and for his work in keeping my modules around, and available. Although I would not refuse any bounty for further development, any bounty which was offered for keeping Custom Contexts alive should be 100% freepbx.
Anyone currently enjoying FreePbx or the existing Custom Contexts module, remember the donate button on the top left… Talk is cheap, put your money where your mouth is.)
I am new to freepbx (2 month) Installed the module and it looked to be working but I have the same problem where the selected customcontext does not show on the extension page. running freepbx 2.5.1.2 core 2.5.1.6 feature code 2.5.0.4
A mention of a fix somewhere??
BTW: will be glad to contribute as soon as I am done learning a bit more to put this in production. 2 weeks…
Thanks
a2billing is one that could be causing the problem as it’s not a part of the FreePBX distribution. Also if you are using version 0.3.3 instead of 0.3.4 of custom context. You can get the latest by going to documenation, module documentation, third party unsupported mods, and selecting it from there.
I’d start a new thread and provide complete details if that is not the issue as it’s known to work on 2.5 using the version posted on this site.
I am running Custom Contexts v0.3.2 on FreePBX 2.5.1.2.
I have made a custom context, called 003 (as in custom number 003). This customer is only allowed to use outbound routes 003a and 003b, but should also be able to make internal calls to other users of the same PBX (extensions). But that seems to be impossible to combine:
I put EVERYTHING on Deny, and then I put the two outbound routes (003a and 003b) on allow. Things seems to be working, the customer dials a number, and the appropriate trunk is automatically chosen based on the dial patterns. Although the outgoing routes 002a and 001a have the same dial patterns as 003a, only 003a will be chosen as route, because of the custom contexts. So far so good.
When trying to call to another extension, I get a message that my call cannot be completed as dialed.
So I found out, that I can allow ENTIRE Basic Internal Dialplan. Then I can make internal calls. But then Asterisk takes the first outbound route available: 001a. Even if 001a is marked as DENY in the Custom Context. Is it really impossible to enable internal calling AND specified custom outbound routes??
I am running Custom Contexts v0.3.2 on FreePBX 2.5.1.2.
I have made a custom context, called 003 (as in custom number 003). This customer is only allowed to use outbound routes 003a and 003b, but should also be able to make internal calls to other users of the same PBX (extensions). But that seems to be impossible to combine:
I put EVERYTHING on Deny, and then I put the two outbound routes (003a and 003b) on allow. Things seems to be working, the customer dials a number, and the appropriate trunk is automatically chosen based on the dial patterns. Although the outgoing routes 002a and 001a have the same dial patterns as 003a, only 003a will be chosen as route, because of the custom contexts. So far so good.
When trying to call to another extension, I get a message that my call cannot be completed as dialed.
So I found out, that I can allow ENTIRE Basic Internal Dialplan. Then I can make internal calls. But then Asterisk takes the first outbound route available: 001a. Even if 001a is marked as DENY in the Custom Context. Is it really impossible to enable internal calling AND specified custom outbound routes??
Well, it seems I am running Custom Contexts v0.3.4, the status line on the page to edit customised configs hasn’t been updated since version 0.3.2
Anyway, the problem is solved.
Under Custom Contexts, I chose to set “ENTIRE Basic Internal Dialplan” to “allow”. This overrules ALL other settings to the Internal Dial Plan, including “All Outbound Routes”. So I denied access to ENTIRE Basic Internal Dialplan, and allowed “ext-local” under heading “Internal Dialplan”.
It would have been more clear, when changing “Entire Basic Internal Dialplan” would result in changing ALL pulldown-boxes under Internal Dialplan to either “Allow” or “Deny”. OR that it was clearly mentioned, that the “ENTIRE”-option overrules all particular settings under Internal DialPlan.
I would suggest starting a new thread to ask this, otherwise you may only get people jumping at you for money to fix the issue if it is broken given the name of this original thread:)
I don’t know the answer to your question as I don’t use custom contexts. However, I’m not aware of anything that may have fundamentally changed that would break custom context other than one possibility. We made some minor changes in how outbound routes are generated. Depending on how fragile the custom context code is, this may have had an effect.
Why don’t you start a new thread asking about this and providing a bit more detail wrt to what is not ‘sticking’ and possibly what is or is not generated based on your changes that may help determine the issue.
due to work responsibilities. I only had time while my office needed what i was doing.