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

Dmitri Pal dpal at redhat.com
Wed Nov 24 17:19:13 UTC 2010


Stephen Gallagher wrote:
> On 11/24/2010 11:26 AM, Dmitri Pal wrote:
> >>> 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.
> >>
> >>
> > Steven, please think about the case when the rule needs to be edited in
> > UI and it has some value for DD - say 1.
> > What you display in UI then? If you do not allow to enter days and you
> > not allow more than 24 hours in the hour field you will fail to
> > translate the rule to the proposed UI.
> > The only option would be to show the raw rule in this case. IMO this
> > does not seem like the best option to me.
> > I think the DD is redundant and other means should be used to schedule
> > windows bigger than 2 days however the HH should IMO allow 1-48 ours to
> > allow specifying a week end outage like:
> > from 1AM Sat to 11PM Sun. If it is more than 2 days it is reasonable to
> > ask to split the rule into several slices.
>
>
>
> I don't want the internal representation to have arbitrary limitations
> set by the WebUI. It's trivial for the WebUI to be designed to convert
> hours to days and reverse. So we can store it in DDHHMM format and
> display it in the WebUI as hours if we really want to.
Sorry but you are completely wrong here.
First this is not an arbitrarily limitation but a usability one.
Second it is not trivial to design web UI especially to be usable.
Current version of the proposed UI (I hope you have seen it) says:
a) No day field
b) Hours field can't accept more than 24 hours
You agreed in the first email that these are reasonable UI limitations.
So IMO it is completely unreasonable to store something that we can't
ever represent in the UI (not because we do not have time, but because
the internal grammar contradicts the suggested UI).

I see three outcomes in current situation:
1) Allow schema to have DDHHMM as you proposed and have UI as Ben
proposed and close eyes to all the ugliness it creates. IMO it is just
wrong and will backfire in future.
2) Adjust UI to match proposed schema - this means we should either add
a day field in the UI or allow the time field to store more than 24 hours
3) Adjust the schema to match the UI - IMO this is the path of least
resistance and most reasonable thing to do.

So to summarize I disagree and stick to my point. Please get together
with Ben on Monday and come to consensus on 2) or 3). I do not care. 1)
Is not an option.

>
> To someone writing a rule by hand, the DDHHMM representation is going to
> be far more useful.
>

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel at redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel




-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the sssd-devel mailing list