Summary:	ASTERISK-03279: Multiple hours/days/weeks for GotoIfTime
Reporter:	jmls (jmls)	Labels:
Date Opened:	2005-01-15 02:42:54.000-0600	Date Closed:	2011-06-07 14:05:10
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I would be nice for the GotoIfTime to support multiple hours/days/weeks. For example open 9-5 mon-fri, 9-1 on sat would be GotoIfTime([9:00-17:00|mon-fri][9:00-13:00|sat]|*|*?open,s,1) open 9-12 and 13-5 mon-fri, 9-1 on sat would be GotoIfTime([[9:00-12:00][13:00-17:00]|mon-fri][9:00-13:00|sat]|*|*?open,s,1)
Comments:	By: Mark Spencer (markster) 2005-01-15 02:54:15.000-0600 Why not just use multiple gotoiftime statements? By: jmls (jmls) 2005-01-15 03:02:40.000-0600 I know that you can use multiple gotoiftime statments. However, this issue came up when I was writing a simple interface for our call queue admins to enable them to change the opening hours when it suits them for each call queue. It would have been a lot simpler (and easier on the eyes when reading the dialplan) to have this feature. After all, you already have ranges (Mon-fri) (13-20) and I just wanted to add to that. However, if everyone is happy with the multiple gotoiftimes, I gracefully withdraw ... grumble grumble :) By: Kevin P. Fleming (kpfleming) 2005-01-15 10:31:09.000-0600 I agree with markster here... there is no efficiency advantage of using one statement over multiple statements, and I don't agree that the proposed syntax is "easier on the eyes" :-) In fact, because of all the punctuation it's hard to see where each time range begins and ends. By: Mark Spencer (markster) 2005-01-15 13:22:57.000-0600 Perhaps it would be easier to use global variables in this case? By: jmls (jmls) 2005-01-15 14:21:08.000-0600 I know that this is probably very "me" specific, but we control all of our queues via a single macro - each q calls this macro with several arguments, one of them being the opening hours. Each q has different opening hours. exten => XXX,1,Macro(callq,5000,lid,custom/q-held,8:00-17:00,mon-fri) exten => YYY,1,Macro(callq,5783,rockwell,custom/q-rock,8:00-20:00,mon-fri) exten => ZZZ,1,Macro(callq,5782,bates,custom/q-bates,8:00-15:00,mon-fri) exten => AAA,1,Macro(callq,5777,switchboard,custom/q-switch,8:00-20:00,mon-sat) Now, without having different macros for each q, which I was trying to avoid, I would have to have some pretty complicated dialplan within the macro to allow for any number of variances in the timeslots. I know that it is possible to do, but then it is also possible to write asterisk  in assembler. My personal view (and that is all it is) is that the dialplan should be as simple as possible, with the complexities being handled by the application. But, as I said, there are people here with much more experience than me and I will withdraw. But not with a simple whimper. If I shout loud enough perhaps someone will take my side and we can then take on the might of the * alliance :) Yeah. And Bill will opensource windows. By: Kevin P. Fleming (kpfleming) 2005-01-15 14:38:01.000-0600 So make your "callq" macro accept as its last argument _another_ macro name, which contains the time specs for that particular queue, and sets a channel variable based on the result of the time comparisons. Then your "callq" macro can use Goto() to jump to the proper place. That's essentially what I use, a macro that sets a channel variable named "officestatus" to one of "open", "closed", "lunch", etc. and then a computed Goto that uses the "officestatus" variable as one of its components. By: Brian West (bkw918) 2005-01-17 14:27:48.000-0600 Can be done with current dialplan.