[Freeipa-devel] Time-Based Account Policies

[Alexander Bokovoy]

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