| 86 | 86 | ('POST_RELOAD_DEBUG','',0,'Display debug output for script used if POST_RELOAD is used<br>Default = not set','select','TRUE,FALSE','FALSE',NULL,NULL), |
|---|
| 87 | 87 | ('RELOADCONFIRM','TRUE',0,'When set to false, will bypass the confirm on Reload Box<br>Default = true','select','TRUE,FALSE','TRUE',NULL,NULL), |
|---|
| 88 | | ('SERVERINTITLE','FALSE',0,'Precede browser title with the server name<br>Default = false','select','TRUE,FALSE','TRUE',NULL,NULL), |
|---|
| | 88 | ('SERVERINTITLE','FALSE',0,'Precede browser title with the server name<br>Default = false' |
|---|
| | 89 | ('TCINTERVAL','60',0,'The polling interval used by the Time Conditions manintenace task, launched by an Asterisk call file used to update Time Conditions override states as well as keep custom device state hint values up-to-date when being used with BLF. This interval should be shorter than the shortest time condition true (open) or false (closed) interval to assure that an override is reset after the current time period has expired that it was set in.<br>Default value 60 seconds.','text',NULL,'60',NULL,NULL), |
|---|
| | 90 | ('TCMAINT','TRUE',0,'If set to false, this will override the execution of the Time Conditons maintenace task launched by call files. If all the feature codes for time conditions are disabled, the maintenance task will not be launched so this is not needed for that condition. Setting this to false would be fairly un-common. On an extremely active system that has constant calls flowing throught all time conditions of interest that might be overriden one might set this to avoid the additional polling that would otherwise occur since calls traversing the time conditions contexts will also maintain all the necessary state information. You may also set this temporarily if debugging a system to avoid the periodic dialplan running through the CLI that the maintenance task otherwise creates.<br>Default = true','select','TRUE,FALSE','TRUE',NULL,NULL), |
|---|
| | 91 | ('DAYNIGHTTCHOOK','FALSE',0,'By default, the Day/Night module will not hook Time Conditions allowing one to associate a daynight manual override with a time condition since now time conditions have their own feature code. If there is already an associaiton configured (on an upgraded system), this will have no affect for the Time Conditions that # are effected. Setting this to true reverts the previous behavior by allowing for the continued use of a daynight toggle to be associated with a time conditon. This can be useful for two scenarios. First, to override a Time Condition without the automatic resetting that occurs with the built in Time Condition overrides. The second use is the ability to associate a single daynight toggle with multiple time conditions thus creating a <b>master switch</b> that can be used to override several possible call flows through different time conditions.<br>Defaul = false','select','TRUE,FALSE','TRUE',NULL,NULL), |
|---|
| 89 | 92 | ('USEDIALONE','FALSE',0,'Un-published option, to use the experimental macro-dial-one in place of macro-dial + dialparties.agi when dialing single extensions. The macro has been very little tested and is otherwise not used at all if this is not set. However, this will enable for those who want to start to test the macro and help flush out its operation for a 2.8 target re #4068<br>Default = false','select','TRUE,FALSE','FALSE',NULL,NULL), |
|---|
| 90 | 93 | ('USECATEGORIES','TRUE',0,'Controls if the menu items in the admin interface are sorted by category (true) or sorted alphebetically with no categories shown (false). Defaults = true','select','TRUE,FALSE','TRUE',NULL,NULL), |
|---|
