Contributors: Robin Jones, Benoit Grégoire, Last update: 2008-03-30 Feel free to contribute and/or format better

Design Document for open hours module

Version 1


Version 1 will only have regular open hours design set allowing time based rules for each day of the week. There will be no limit for the amount of rules that can be specified, but a rule should not be able to overlap with another rule. A button will also be added to allow a network or a node to be instantly closed for a specific duration (in minutes) with a specified message, to allow for things like building events to take place.

Design choices.

Would the network owner prefer that as default (so if there are no rules defined), the hotspot is open or closed. When entering the rules, would the user prefer to enter the open hours, or the closed hours. Although specifying the open/closed time with a duration is a good idea, for the regular open hours design, I think specifying a closed/open (opposite of the first) time would be better, as the rules are not allowed to pass the dateline anyway.

HCI design for GUI

The first prototype of the user page is:

A prototype of the user page

There would also be a hidden DIV which will show if the hotspot has been closed manually. Another feature would be to allow (if specified in the network settings) users to continue to the portal, or to see a list of websites in the walled garden. This maybe with a menu that says “Sites I can still visit”. Another option would be to replace the login page with the closed screen, with a “secret button” for those administrators.

An Example of how the admin page could work:

A prototype of the admin page

Pseudo Code

CREATE TABLE RegularTimeRules
	network_id text,
	node_id text,
	startTime time NOT NULL,
	endTime time NOT NULL,
	day_of_week int NOT NULL,                    //1 - 7,

/** Return all time rules for network
static function getAllTimeRules() { 
	$db = AbstractDb::getObject(); 

	$db->execSql("SELECT * FROM RegularTimeRules where network = $network", $objects, false); 
	if ($objects == null) { 
throw new Exception(_("No Rules are associated with this network.")); 
	return $objects; 
/** Return a matching time rule
static function getAllTimeRules() { 
	$db = AbstractDb::getObject(); 

$db->execSql("SELECT * FROM RegularTimeRules WHERE network = $network AND Weekday = $currentDay AND StartTime < $currentTimestamp AND EndTime > $currentTimestamp ODRER BY desc LIMIT 1", $objects, false); 
	return $objects; 

Version 2

Specification Version 2 will add the functionality of a php calendar to the admin interface, the rules defined in this calendar will override Version 1 (regular open hours rules). Times in this ruleset will be allowed to cross the dateline. They will also be able to reoccur and do nearly any other rule or pattern that you can do with a meeting event in a complex calendar application such as outlook or lotus. You will also be able to use (as a network setting) either version 1, version 2, or both, this will allow for all business senarios

An example of MS Outlooks interface example of rules that can be set in MS Outlook.

A good reference point for time based rules can be found here: it includes C# source code for time patterns, which could be converted to PHP for use in wifidog.

Now all we need is someone with the knowledge to code it...


I would like to get the ball rolling on the implementation of an Opening Hours ruleset:


First stab at the WiFidog?-postgress-schema.sql

CREATE TABLE hotspotopenhours
         node_id text NOT NULL,
         open_time text NOT NULL,
         close_time text NOT NULL,
         day_of_week text DEFAULT 0 NOT NULL,                    //0 - 7,  0 = all
         day_of_month text DEFAULT 0 NOT NULL,                   //0 - 31, 0 = all
         month_of_year text DEFAULT 0 NOT NULL,                  //0 - 12, 0 = all
         specific_date date

B: Not a bad start. Ideally, we want a little more expressiveness to allow for some holidays defined as the second monday of october, or the monday before may 25th). One (bad) way I can think of is to say that if both day_of_month and day_of_week are defined, the date will be the first day_of_week that is on or after day_of_month. But the SQL to calculate that may be quite ugly. Also, while the UI will provide an opening and closing time, we probably do not want to store the closing time. Instead, we want to store the opening duration. That way, we can deal cleanly with places that are open across a date change (such as bars which may be open from 3pm to 3am).


And my probably awfull and incorrect stab at an sql statement to process the rule! I have not gone through the code enough to find where this statement should be put and also the Vars are probably incorrect but hopefully readable!

SELECT * FROM hotspotopenhours 
WHERE $nodeid = node_id 
AND ($timestamp >= open_time 
AND $timestamp < close_time) 
    $dayofweek = day_of_week 
    AND $dayofmonth = day_of_month 
    AND $monthofyear = month_of_year 
    OR date = now) 
THEN true 
ELSE false

B: Is see some issues with that query:

  • While that query may do for now, we need a much more complex query than that if we want this to scale well: we need to find the date of the next transition form open to closed (and ideally vice-versa). That way, once we have tokens, we won't have to re-run the algorithm at every ping.

The only other thing I can see that is wrong is it would be prefered that specified dates would have priority, then day of week, month etc with a value greater than 0 and lastly those with a value of 0. This may be done through an IF statement.

if specified_date is not null then select return  
 end if  
 If day_of_week OR dat_of_month OR month_of_year < 0 then return  
 end if 

B: It may be simpler and faster to do it through clever use of ORDER BY and LIMIT 1

Bypassing opening hours for some users

lastly I thought about an administrator/MAC passthrough rule, but don't know the best way of achieving this yet!

B: This is easy with the new role system, by simply adding a NODE_BYPASS_OPENING_HOURS permission.


Someway of defining "Late" as a closing hour option might be nice.