[Freeipa-devel] Time-Based Account Policies

[Petr Vobornik]

On 08/03/2015 04:30 PM, Alexander Bokovoy wrote:
> On Mon, 03 Aug 2015, Stanislav Laznicka wrote:

<snip>

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

Better to ask UX developer for an opinion ;) (Kyle CCd)
-- 
Petr Vobornik