[SSSD] Other issues with HBAC calendar
Hi,
During the conversation with Ben and Kyle today over the calendar screen
two things came up:
1) Time zone
2) Duration
Time zone
It makes perfect sense to allow the admin to enter the rule and specify
the time zone that the admin used to enter the time. Internally it will
be converted to UTC but for the purpose of easier rule creation
specifying time zone is helpful. Our grammar right now does not allow
saving the zone since we plan to convert time to UTC, however when the
value is fetched from the LDAP and presented for editing it is unclear
which time zone it was entered in. Also there are two approaches to
dealing with time zone information in general. Imagine you have a drop
down with time zones. Imagine you entered time and then change the
selected time zone in the drop down. Should the time you entered be
automatically adjusted? First approach says "yes" but that means that we
will have to implement a complex time recalculator since in corner cases
the time difference between the time zones will affect the starting. The
second option is to say: the time zone is just a specifier for the whole
time rule indicating that the time values were entered in the given time
zone. The when you change the value of the time zone you do not
recalculate anything. With the right UI structure this can be made more
obvious.
However when the value fetched from the LDAP and displayed it might be
useful to recalculate so I see two options how we can deal with the time
zones.
a) Do not save the time zone but recalculate the time (and date ???)
when you change time zone in the drop down both in add and edit cases.
When you fetch and display always use UTC but allow admin to change the
"timezone view" at his will.
b) Save time zone in the rule. As Simo pointed the time zone definition
change from time to time so it makes sense to actually save offset and
timezone as additional hint. This way we can easily convert the time
stamp into the specified time zone and back at save and retrieval with
no need to implement complex logic in the UI.
IMO the second option is simpler but requires yet another change to
grammar. I suggest we add offset and time zone as optional fields
somewhere at the end of the rule or after start time.
Duration
New grammar allows DDHHMM for the duration. UI proposes to limit the
duration to less than 24 hours since more than 24 hour windows can start
overlapping and thus allowing to enter duration days was confusing to
the users who tried the UI. We need to reconcile this a bit between
what can be stored and what can be displayed. IMO it makes sense to
allow windows more than 24 hours (regular service window over weekend
for example). But on the other hand I see how having a separate field
for number of duration days in the UI might be confusing. I would vote
for not having days in the UI at all but allowing any numeric value to
be entered into the hours field. This however rises a question whether
we want to have the duration be in DDHHMM format in grammar or in just
NMM format where N is any numeric value that represents unlimited number
of hours. Thoughts?
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/