[Freeipa-devel] [PATCH] 918, 919 update sudo schema

[Jan Cholasta]

Dne 14.12.2011 15:23, Rob Crittenden napsal(a):
> Jan Cholasta wrote:
>> Dne 14.12.2011 05:20, Rob Crittenden napsal(a):
>>> The sudo schema now defines sudoOrder, sudoNotBefore and sudoNotAfter
>>> but these weren't available in the sudorule plugin.
>>>
>>> I've added support for these. sudoOrder enforces uniqueness because
>>> duplicates are undefined.
>>>
>>> I also added support for a GeneralizedTime parameter type. This is
>>> similar to the existing AccessTime parameter but it only handles a
>>> single time value.
>>
>> You should parse the date/time part of the value with
>> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it manually,
>> that way you'll get most of the validation for free.
>
> Yes but it gives a crappy error message, just saying that some data is
> left over not what is wrong.

IMHO having a separate error message for every field in the time string 
(like you do in the patch) is an overkill, simple "invalid time" and/or 
"unknown time format" should suffice (we don't have errors like "invalid 
3rd octet" for IP adresses either).

>
>> Also, it would be nice to be able to enter the value in more
>> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and normalize
>> that to LDAP generalized time.
>
> When dealing with time there are so many ways to input and display the
> same values this becomes difficult.
>
> I'd expect that the times for these two attributes will be relatively
> simple and I somehow doubt users are going to want seconds, leap seconds
> or fractions, but we'll need to consider how to do it for future
> consistency (otherwise we could have a case where time is entered in one
> format for some attributes and another for others).
>
> If we input in a nice way we need to output in the same way.

We could make the preferred input/output time format user-configurable, 
defaulting to current locale time format. This format would be used for 
output. For input, we could go over a list of formats (first the 
user-configured format, then current locale format, then a handful of 
"standard" formats like YYYY-MM-DD HH:MM:SS) and use the first format 
that can be successfully used to parse the time string.

>
> rob

Honza

-- 
Jan Cholasta