Bug #6468
closedFirewall scheduler allows you to set invalid time range
100%
Description
For example, it will accept 06:00-52:00. See screenshot
Files
Updated by Phillip Davis over 8 years ago
It was never intended that users should be able to edit the day and time range in each of the rows of a schedule. If a day-time-range row is not correct, then the workflow is to delete the row and then enter the correct desired day-time-range using the calendar pad and start hour/minute stop hour/minute drop-down fields.
I set the day, start time and stop time to readonly in pull request https://github.com/pfsense/pfsense/pull/2999
Updated by Chris Buechler over 8 years ago
- Category changed from Rules / NAT to Web Interface
- Status changed from New to Feedback
- Affected Version set to 2.3.x
PR merged, thanks Phil
Updated by Phillip Davis over 8 years ago
- % Done changed from 0 to 100
Applied in changeset a9dafcba7543ee455bc3999f655010d9e2aa35ed.
Updated by Erik Ruedin over 8 years ago
@Philip: Even if it was not an intention, it was best what happened. It was definitively easier to modify one single time instead of deleting and reinsert a modified time line. It was possible to set any time instead of a period of 15 minutes. In version 2.2.x it was a little bit better because Editing of a time row was possible. Now, it's a step back into an artificial more complex process, especially if you try to change the time on a mobile device. Bummer!
Updated by Phillip Davis over 8 years ago
Erik Augustsson: If someone puts the validation code in place to check text-entries in those boxes for validity, then they could be re-enabled for data entry :)
And there needs to be some thought given if other than 00, 15, 30, 59 are allowed in the minutes. The cron job actually fires up at 00, 15, 30, 45, 00... to (potentially) rebuild the ruleset implementing the "current" scheduled rule(s). If a rule is entered to start at minute 22 (for example) then actually it will not be effective until minute 30 anyway.