Stephen Gallagher wrote: > During a discussion today about how to represent the HBAC grammar in the > FreeIPA GUI, it became apparent that there was a limitation in the > grammar. Specifically, it's not possible to describe in a non-ambiguous > way "The first Wednesday of the month". > > Right now, this would be described by: > accessTime: periodic monthly week 1 day 3 0800-1700 > > However, this literally means "Wednesdays that appear as the first week > on a wall calendar". Meaning that if the month began on a Thursday, this > rule would not fire this month. Thus it's not behaving in a way that > would be reasonably expected by a user. > > After extended discussion, Simo, Ben and I discussed replacing this > week-of-the-month concept with a septet-of-the-month concept instead. > > This would be described by: > accessTime: periodic monthly septet 1 day 3 0800-1700 > > and would literally translate as "The wednesday that exists within the > first septet of the month". The first septet being the range of day 1 > through day 7, the second septet being day 8 through 14, and so forth. > > We all feel that this would map closer to a user's expectation when > describing "the Nth Wednesday of the month", since it's a guarantee that > Wednesday will appear only once within a septet. > > This will require two changes to the HBAC schema. First of all, we plan > to drop the week-of-the-month concept entirely and replace it with > septet-of-the-month. This is being done to eliminate the ambiguity > entirely. Secondly, we will need to describe day-of-the-septet in the > grammar (where the day of the septet describes the name of the weekday, > and not its numerical position within the septet, as that would be a > useless and complex duplication of the day-of-the-month concept). > > > In a related note, we also discussed how to handle describing activity > windows that cross the midnight boundary. It's my recommendation that we > should handle examples like the following by breaking them into two > separate accessTime attributes, one that describes the portion preceding > midnight and describes the set of days wherein the block starts, and a > second accessTime attribute that is offset by one day and describes the > portion taking place after midnight. > > Second-shift (17:00-01:59, M-S*) *starts Monday, ends Saturday morning > becomes > accessTime: periodic weekly day 1-5 1700-2359 > accessTime: periodic weekly day 2-6 0000-0159 >
I agree with the proposal the only issue I see is the issue of the time zone of the user. When the user schedules the window it should be clear what time zone he is using. If we in v2 use UTC for all I am fine but if we allow user to enter window in the local time to his machine and then rely on the client UI/CLI to convert it to UTC we can face a problem of the local time window not crossing midnight while the UTC window will cross the boundary. We need to define how this case will be handled and how we interpret the input. Please add the clarification about this. _______________________________________________ sssd-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/sssd-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
