Custom Contexts Module

Beta Release - please critique - took me only one day ;)

Someone will have a look.

Ok, maybe if I add some features it will get more attention! ;)

Version 0.1.1 - now has optional Time Groups which allows you to name a set of times to enable the user to not only deny or allow access to certain dialplan contexts, but to control access to each context by time, date or day also.
This would, as a side benefit, take care of #774 (which i was anyhow thinking of implementing as its own module, to allow other modules access to the time conditions of it, but decided against that because I allow multiple time matches per saved time group, which works well for my purpose (includes) but would not work easily with a GotoIfTime?)

BTW: I have a couple more modules up my sleeve, (hint: #691, #1479) but I figured I'd test the waters with this one since it seemed to be the most sought after. I know you guys are busy trying to put out 2.2 final, but what can I do to get this thing into the module repository?

naftali

Version 0.1.1 Still Beta but fully functional!- Please test and post comments!

I've started to look into this, but it's my opinion that we build this into core, since it's a critical feature that many other modules could use.

We're also still deciding the future of the gui API. At this point, it looks like guielements is going to be replaced by something more well designed, but it's not clear what exactly, just yet. we're trying to limit the use of it right now to avoid reprogramming lots of stuff (just a heads up).

Taking a quick look .. the customcontexts_module table is not needed, that information is already managed by the freepbx module system. I'm also unclear of what the separate *_list tables are for? some functions (with 'admin' in the name) use those, while the other ones use the tables without _list.

If you'd like to build it into the core, that's fine, but it seems not to be happening. There have been dozens of feature requests about this point open for months! :(
I do like my implementation, though, as it allows quite a bit of control and flexibility.
If you do build it into the core, feel free to use my ideas/code

I realized already that although gui elements seemed to be the new thing, they were not the solution to everything. It would not take much time though to port my code to any new gui system that is used.

You're right about the version variable, that was added at last minute, but I did want to be able to query for my module name, and display name, neither of which I could access from the modules table.

Sorry if my comments in the file were not enough. In order to make available to the user all of the contexts generally included in from-internal-additional, I had to know them. I did not want to rely on a predefined set of includes which I would ship because I wanted to allow for new modules/features and besides, every outbound route becomes a new context. Therefore I hook the hookGet_config and store all of the contexts I can get my hands on into the table customcontexts_includes_list. The way I know which contexts to parse for includes is the table customcontexts_contexts_list. These 2 tables are ONLY for the purpose of listing available contexts to Alow/Deny!!!!!!

The remaining tables are used to store the actual custom contexts and their includes.
The admin page (and all admin functions) are used to allow the admin to tell me where to look for/parse includes (eg. from-internal-additional, outbound-allroutes, etc.) and to type a simple description for each include so it shows up nicely on the Custom Contexts page for the user. The actual custom contexts are created/filled on the Custom Contexts page not the Admin page.
I put quite a bit of thought into the design, so please comment if you feel something should be done differently. Perhaps it would be lees confusing if the Admin page were under the tools menu... In case you haven't noticed, this module has 3 pages.

For help installing read Modules Help.

Notwithstanding that this is a very well done implementation of a much needed feature, I may have found something (a minor bug). I'm running freePBX 2.2.0rc1.

I installed version 0.1.1 and created a Context called "Test" using Custom Contexts option. Then, after saving/submitting and doing backend reload, I removed it, and did a backend reload again.

Next, I created a new context using Custom Contexts option again, but with a different name, and the original now referred to as "ext-test" is still showing up under "Internal Dialplan" with Allow/Deny listbox control to right.

not sure for whom you posted the link to ModulesHelp? ... I just need help getting this into the online repository ;)

what you found is not a bug. it is a feature, and not part of my module at all!

It is part of the Feaure Codes/Core and is used to test your dialplan (inbound routes, fax, etx.) and is as follows.

[ext-test]
include => ext-test-custom
exten => 7777,1,Goto(from-pstn,s,1)
exten => 666,1,Goto(ext-fax,in_fax,1)
exten => h,1,Macro(hangupcall,)

; end of [ext-test]

My comment regarding help installing was for people that might not know exactly how to take your work and put it into production on their machine. I had never installed a module onto a production/development system prior to learning about your module. I did a little research to learn how, and just thought I would save the next person the trouble of doing the research.

BTW...I implemented your module in a multi-tenant production environment for one of my existing customers with great success. It was something I was dreading until I found your module. It makes such much more sense to do it the way you did in the module, so that custom code I normally write can't be lost/overwritten by others, etc.

I haven't had time to play with the other two pages in your module, but I will this weekend on my development system. Great work!!!

Replying to naftali5:

not sure for whom you posted the link to ModulesHelp? ... I just need help getting this into the online repository ;)

what you found is not a bug. it is a feature, and not part of my module at all!

It is part of the Feaure Codes/Core and is used to test your dialplan (inbound routes, fax, etx.) and is as follows. {{{ [ext-test] include => ext-test-custom exten => 7777,1,Goto(from-pstn,s,1) exten => 666,1,Goto(ext-fax,in_fax,1) exten => h,1,Macro(hangupcall,) ; end of [ext-test] }}}

This works great except for a bug in version 0.1.1 - if, after this module is installed, you create a new outbound route, and move it up so it's not the last one (thereby changing the sequence of routes), the custom contexts module gets confused and starts displaying both the old and new route sequences. Assuming that can be fixed, I would hope that this module could be included as a standard module soon because it seems really useful, even for small home users that may want to restrict certain extensions either by time or by disallowing certain features (like ChanSpy? and ZapBarge?!), or by the use of certain routes (no calls that cost money from kids' rooms, etc.).

Assuming this does get included, may I suggest that some new system recordings be considered, for the people that would be using this module in real business situations - for home use I'd just record something that says "Hey! Why are you dialing THAT number from YOUR telephone?!" :-)

1) "I'm sorry, the call you have made cannot be completed from the extension you are using." (or "... the number you have dialed cannot ..." or some variation thereof).

2) "If you feel you have reached this recording in error, please contact ..."

3) "... your system administrator." (the alternate ending would be "customer service" which is already an included recording).

I decided to try and write some preliminary usage instructions for this module, based on an IRC conversation I had with naftali5 last night (he can correct me if I am wrong about anything, but I figured it might be helpful to at least get something out so people could experiment with this module. I can't write code, but every now and again I can write barely-literate documentation):

Unofficial usage instructions for the Custom Contexts module:

Most users will not need to do anything in the Custom Contexts Admin section - that is for advanced users. When you "add" or "remove" contexts from the Admin, you are not really adding or removing anything, you are just telling the module where to find all of the includes to list. By default there are three includes which should be sufficient for most users: from-internal, from-internal-additional, and outbound-allroutes. So, skip the Custom Contexts Admin section until you feel comfortable making changes there.

The first thing that you will want to create is time groups, if you plan to use those. The reason for doing this first is so that they will become available in the drop down selections when you create your custom contexts. For each group you create, you can decide which times it should be available. You can define multiple times within one named group, and then each named group then becomes available along with allow/deny for each choice under a custom context (this will become clearer further down), so you can allow, deny, or choose your time group to allow only at specific times/dates/days.

One thing to bear in mind when creating time groups is that this module will not forcibly end calls in progress. So if, for example, you have "free" calling on a particular route from 9:00 PM to 7:00 AM, you probably don't want to set the end time right at 7:00 AM, because then someone could make a call at 6:59 and talk for several minutes into the non-free period.

Now, to actually create a Custom Context, you go to the Custom Contexts page, and add a context - note that the context name may NOT contain spaces. Then add a description (spaces are okay here) and submit.

Once the context is created, you can edit it to allow or disallow the features and routes you want a particular extension (or group of extensions) to have access to. Choose "Allow" or "Deny" for each application or route - you may wish to allow all, except for the items you specifically wish to restrict (for example, you probably want to restrict ChanSpy? and ZapBarge?!). If you have created any time conditions, it will also be possible to select those, to allow a feature or route to be accessed only during certain times.

One thing you need to watch out for is that the bottom item in the Internal Dialplan section is outbound-allroutes. If you allow outbound-allroutes, it will override the individual route selections in the following section. So if you want users of this context to have access to all outbound routes, you can just allow outbound-allroutes and ignore the individual route sections (leave them all set to "deny"). But if you want to select routes individually, then make sure that outbound-allroutes is set to "Deny". Of course, you could also use non-overlapping time conditions for outbound-allroutes and individual routes.

Finally, you need to go to your Extensions page and select each extension for which you wish to use a custom context. On each individual extension page, you should now see a dropdown to allow you to select a custom context. This drop-down is simply a convenient way to fill in the correct context in the "context" textbox. When you click on a custom context, it replaces whatever is currently in the "context" textbox with your new selection - if you choose "Default", it resets the extension back to the default "from-internal" context. Don't forget to click "Submit", and then click the red bar when you are all finished making changes.

NOTE that if you disable or uninstall the Custom Contexts module, you MUST reset all the extensions back to the default "from-internal" context. If you delete a time group, anyone who had that time limitation becomes "Allow" with no time restrictions. If you add a new outbound route, by default that route is set as "Deny" in the Custom Contexts, so you should go into each context and set it to "Allow" (or use a time condition) where appropriate.

Kudos to you wiseoldowl!!!
You ceratainly made the time I spent with you last night well worthwhile.
I could not have done better myself. :)
hope you dont mind I took the liberty of posting it on the wiki
naftali
p.s. thanks for pointing out that bug. I had it fixed already in my development version, it can simply be put as - deleting a route doesn't remove it from the list.
One more caveat I forgot to mention. After you add an outbound route, it is not available until you reload.
Lastly, I must thank you for one more thing. I read your post, and thought to myself "change the sequence of the routes"!?!? I knew you could change the sequence of trunks used, and wished I could change the sequence of routes! I checked, and it is there! I don't know when this feature was added, but I don't think it was there in AMP.

version 0.1.2

Changelog

*0.1.2* Bugfixes- deleted routes, etc. now are removed.
        Context tests for spaces and illegal chars.
        Moved admin to tools to reduce confusion.
        Added option to allow entire internal dialplan. (Usefull for time limit on everything)
        Made description for outbound-allroutes clearer that allowing overrides to allow all routes.
*0.1.1* Still Beta, added time groups and bugfixes
*0.0.1* Beta release

version 0.1.3 - new feature

version 0.1.3

Changelog'

*0.1.3* Made it obvious when allowing one include may allow another entire context.
*0.1.2* Bugfixes- deleted routes, etc. now are removed.
        Context tests for spaces and illegal chars.
        Moved admin to tools to reduce confusion.
        Added option to allow entire internal dialplan. (Usefull for time limit on everything)
        Made description for outbound-allroutes clearer that allowing overrides to allow all routes.
*0.1.1* Still Beta, added time groups and bugfixes
*0.0.1* Beta release

Known Issue

outbound routes are not sorted within your custom contexts as they are normally.

version 0.2.0 I'm going to call this a new feature, see changelog

Changelog

*0.2.0* Added priority feature to allow the user to control in what order the allowed contexts are included.

The feature is optional, you can disable it using a link on the page.

If you do disable it, your previous prioritizing is lost on the next submit.

version 0.2.1 New Feature

Version 0.2.1 Changelog

*0.2.1* Added Duplicate Context option to easily copy an entire set of rules.

version 0.2.2 bugfix

version 0.2.2 Changelog

*0.2.2* Bugfix: Duplicate Context now copies the priority also.

I posted the gz files on a web space that I have access to. This centos wget bug is bogus. For some assorted asterisk files go to. http://www.zelie.com/~n3glv/asterisk/

version 0.3.0 New Features see changelog

Version 0.3.0 Changelog

*0.3.0* New Features:
Allow or Deny based on pattern matching.
Failover Destination (one for regular extension, one for failed feature codes)
Bugfixes:
Adjusted Gui, Duplicate context, now duplicates the description too.

code to download...

wget http://www.freepbx.org/trac/attachment/ticket/1447/customcontexts-0.3.0.tgz?format=raw
mv customcontexts-0.3.0.tgz?format=raw customcontexts-0.3.0.tgz
tar -xzvf customcontexts-0.3.0.tgz

version 0.3.1 minor changes

Version 0.3.1 Changelog

*0.3.0* Now prompts on delete. After duplicate you are editing new context.

code to download

wget http://www.freepbx.org/trac/attachment/ticket/1447/customcontexts-0.3.1.tgz?format=raw
mv customcontexts-0.3.1.tgz?format=raw customcontexts-0.3.1.tgz
tar -xzvf customcontexts-0.3.1.tgz

Oops. forgot to document the biggest change. you can now rename contexts.

I think this is a good one for 2.2 - whilst the guielems rewrite will happen in 2.3, this is a nifty module for 2.2. Any complaints?

version 0.3.2 new features

Version 0.3.2 Changelog

*0.3.2* Optional PIN to protect failover destination.
Contexts can now be used as destinations. An IVR menu, Time Condition, etc. can now send a caller into a custom context.

(This last feature requires a bugfix in 2.2 after rc1. bug #1549)

(the rest of the module will work without it)

code to download

wget http://www.freepbx.org/trac/attachment/ticket/1447/customcontexts-0.3.1.tgz?format=raw
mv customcontexts-0.3.2.tgz?format=raw customcontexts-0.3.1.tgz
tar -xzvf customcontexts-0.3.2.tgz

version 0.3.3 bugfix and features see changlelog

Verision 0.3.3 Changelog

*0.3.3* Added Set All option to quickly allow/deny all.
Fixed bug which caused routes to be denied after rename/sort/or delete other route.

code to download (sorry it was wrong on last verison)

wget http://www.freepbx.org/trac/attachment/ticket/1447/customcontexts-0.3.3.tgz?format=raw
mv customcontexts-0.3.3.tgz?format=raw customcontexts-0.3.3.tgz
tar -xzvf customcontexts-0.3.3.tgz

Milestone 2.3 deleted

This should be integrated to core: see #1690

There is a bug:

mysql> ALTER IGNORE TABLE customcontexts_contexts ADD dialrules VARCHAR( 1000 ) NULL; ERROR 1074: Too big column length for column 'dialrules' (max = 255). Use BLOB instead mysql> ALTER IGNORE TABLE customcontexts_contexts ADD dialrules VARCHAR( 255 ) NULL; Query OK, 0 rows affected (0.00 sec) Records: 0 Duplicates: 0 Warnings: 0

Varchar only accepts 255 (in mysql 4.0)

Moved to Contributed Modules Repository

Replying to p_lindheimer:

Moved to Contributed Modules Repository

Hi,

Is this module still relevant ? Was it incorporated in the FPBX distribution ?

Thanks.

It is located in svn under the contributed_modules branch. It is not officially part of FreePBX but you can use it at your own risk. There are not plans to incorporate it at this time because of planned changes that will gain the same functionality but break the way this module expects things.

You can get the most updated version of this module (and other contributed modules here):

http://mirror.freepbx.org/modules/release/contributed_modules/

(In [9817]) re #1447, re #1690 - simple changes, just enough to make CustomContexts work with 2.8

(In [9818]) re: #1447, #1690; reverting changes to make way for #4335

(In [9819]) re #1447, #1690; reverting r9817 to make way for #4335