[SSSD] [Freeipa-devel] Other issues with HBAC calendar

Stephen Gallagher sgallagh at redhat.com
Tue Nov 23 15:44:45 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/22/2010 10:54 PM, Dmitri Pal wrote:
> Hi,
> 
> During the conversation with Ben and Kyle today over the calendar screen
> two things came up:
> 1) Time zone
> 2) Duration
> 
> Time zone
> 
<snip>

Time zone should always be entered relative to the server, not the user
entering it. This should be clearly identified in the UI. Then there's
no ambiguity upon reading it back out, as it is ALWAYS relative to the
server.

> 
> 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?
> 

I agree that we don't want to have > 24 hours in the UI.

DDHHMM is easier to parse, and I can't come up with an example where a
window of longer than 99 days makes sense. Instead, it should be a
recurring event.


- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkzr4WkACgkQeiVVYja6o6PmXgCbBKNR3qb5uh2hJlfF1TsQLkMz
yx4AnAuGm/PADzU9CFa2+DRCmLbDxq1k
=7+wV
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list