On Mon, 03 Aug 2015, Stanislav Laznicka wrote:
dragons may appear, although with a tiny tiny possibility of a
golden treasure in the end.
Yes, I think intervals are required.
Alright. I gave it a little thought considering the current state of
the language for time rules and considering where I should go with
these intervals. The thing about the 'interval' in iCalendar is that
to use it it is necessary to also add at least the 'frequency' and
'startdate' elements to the language. With that, adding 'enddate' and
'count' optional elements should not be that bad. What I am hoping for
is that the same functionality as in iCalendar can be achieved here
and so far I do not see why not.
Yep.
3. The mockups for HBAC time policies show quite a wizard-like UI.
While I might be very wrong here, I was thinking of rather a
simple UI where user would be able to set the values for each of
the rule keywords (timeofday, dayofweek, ...) directly in some
text input fields with possible help of JavaScript, that would add
text description to the user input (e.g. "Monday to Friday" with
user input "1-5" at the dayofweek input field).
With JavaScript support your wizard-like approach would still work
within the same page -- instead of moving 'next', you would need to
modify a number of available input fields based on selected items.
That's possible and I don't see much of trouble with it.
4. Do we want some special settings for "absolute" time policies
(policies that start and end at certain time in year)? The issue
now would be that some of such rules would have to be broken down
in more than one time rule (e.g. rule starting at a certain time
of a day in a month in one year and ending at a certain time, day
and month of a different year might get broken down to up to 6
rules if I count right). This could actually be solved by a UI
wizard-like setting where the user gets to pick the dates and
times of the rule, a conversion method would need to be created
and such a thing would then work for the CLI, too. Still, usually
more than one time rule would be created for such cases.
Same here.
I might not have expressed myself clearly there, for which I am sorry.
I was rather thinking that instead of different 'screens' for
different time scenarios, like "Yearly", "Daily", etc., user should be
able to set all the values in one UI pop-up screen directly as number
values in text fields (with the exception of "absolute" time policies,
perhaps). While the user experience may suffer a bit, to me it seems
more clear, readable and flexible than to have some elements such as
checkboxes and selects take care of that (although the values around
the "interval" from iCalendar discussed here earlier would probably
need just that). Hopefully, I made myself clearer here :)
If you are able to structure types of scenarios clearly, use accordion
pattern to present them at the top level, like here:
https://www.patternfly.org/widgets/#accordion (we are using PatternFly
in our UI). Do per-scenario options in each panel as needed.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
