Project

General

Profile

Bug #6468

Firewall scheduler allows you to set invalid time range

Added by Marco Novielli almost 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Web Interface
Target version:
Start date:
06/07/2016
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.3.x
Affected Architecture:

Description

For example, it will accept 06:00-52:00. See screenshot

firewall scheduler bug.tiff (118 KB) firewall scheduler bug.tiff Marco Novielli, 06/07/2016 07:41 PM

Associated revisions

Revision a9dafcba (diff)
Added by Phillip Davis almost 3 years ago

Fix #6468 Do not allow edit of day and times

in rows of time ranges for a schedule.
The code was always intended that the user uses the calendar pad and start hour/minute stop hour/minute drop-down fields to enter days and time range. If an existing day-time-range is wrong, then the workflow is to delete the row and then enter the correct day-time-range using the calendar pad and start hour/minute stop hour/minute drop-down fields.

I left the Description field as editable - there is not harm here in letting the user fixup text in any of the dsecriptions for each row.

Revision 09cd43a8 (diff)
Added by Phillip Davis almost 3 years ago

Fix #6468 Do not allow edit of day and times

in rows of time ranges for a schedule.
The code was always intended that the user uses the calendar pad and start hour/minute stop hour/minute drop-down fields to enter days and time range. If an existing day-time-range is wrong, then the workflow is to delete the row and then enter the correct day-time-range using the calendar pad and start hour/minute stop hour/minute drop-down fields.

I left the Description field as editable - there is not harm here in letting the user fixup text in any of the dsecriptions for each row.

Revision bcd856f5 (diff)
Added by Phillip Davis almost 3 years ago

Fix #6468 Do not allow edit of day and times

in rows of time ranges for a schedule.
The code was always intended that the user uses the calendar pad and start hour/minute stop hour/minute drop-down fields to enter days and time range. If an existing day-time-range is wrong, then the workflow is to delete the row and then enter the correct day-time-range using the calendar pad and start hour/minute stop hour/minute drop-down fields.

I left the Description field as editable - there is not harm here in letting the user fixup text in any of the dsecriptions for each row.

History

#1 Updated by Phillip Davis almost 3 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

#2 Updated by Chris Buechler almost 3 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

#3 Updated by Phillip Davis almost 3 years ago

  • % Done changed from 0 to 100

#4 Updated by Chris Buechler almost 3 years ago

  • Status changed from Feedback to Resolved

fixed

#5 Updated by Erik Ruedin almost 3 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!

#6 Updated by Phillip Davis almost 3 years ago

@Erik: 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.

Also available in: Atom PDF