We should re-architect time conditions such that it becomes an 'abstract' set of timeconditions with no actions associated with it. Then modules that want to include time conditinions can poplulate a menu obtained by a method supplied by the timecondtions module.
The first step would be to separate the 'goto' from the current 'timeconditions' and make a new page/module to create the goto conditions that pulls from this class. Then other modules can use the same time conditions for other purposes.
This is analogous to how some SOHO routers I've looked at work. You setup time conditions that can be used in menus like internet availability, when port forwarding should be restricted, etc. It provides for one place to setup the fairly 'complex' time condition menu.
An example of where this could be immediately applied is outbound-allroutes. Today the routes get generated as such:
[outbound-allroutes]
include => outbound-allroutes-custom
include => outrt-001-Emergency
include => outrt-002-Local
include => outrt-003-LongInternational
as an example. With a very minor tweak, using the proposed timeconditons class, you might create a timeconditions that looks like the following, (say you had free PSTN calls on weekends...)
[outbound-allroutes]
include => outbound-allroutes-custom
include => outrt-001-Emergency
include => outrt-002-Local
include => outrt-003-LongInternational|*|mon-fri|*|*
include => outrt-004-PSTNLongInternational|*|sat-sun|*|*
This is an example of an 'easy win' since the format of oubound routing already lends itself to a structure that could quickly adopt this. Plenty of other modules could adopt time conditions in various creative ways if they could simply include a class method which gives them the pulldown menu of existing timeconditons to choose from, and the associated methods in functions to retrieve and include the info in the generated dialplans.
I've assined it to 2.2 - but would probably be easy to tweak what we have and actually get this in 2.1.
