On 11.8.2016 12:34, Stanislav Laznicka wrote:
> I updated the design of the Time-Based HBAC Policies according to the
> discussion we led here earlier. Please check the design page
> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest
> changes are in the Implementation and Feature Management sections. I also
> added a short How to Use section.
On the high level it all makes sense.
ad LDAP schema
1) Why accessTime attribute is MAY in ipaTimeRule object class?
Does it make sense to have the object without accessTime? I do not think so.
Also, it could be good to add description attribute to the object class and
incorporate it into commands (including find).
2) Besides all this, I spent few minutes in dark history of IPA. The
accessTime attribute was introduced back in 2009 in commit
"55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new schema for
The commit does not contain any reasoning for the change but I can see that
the attribute is already used as MAY in old object classes ipaHBACRule and
Is any of these a problem?
Why is it even in ipaSELinuxUserMap object class? Commit
55512dc938eb4a9a6655e473beab587e340af55c does not mention any reason for doing
I cannot see any other problem so the low-level stuff is good and can be
ad User interface
We need to polish the user interface so it really usable.
At least the web interface should contain some shortcuts. E.g. when I'm adding
a new HBAC rule, the "time" section should contain also "something" to
immediately add new time rule so I do not need to go to time rules first and
then go back to HBAC page.
Similarly, dialog for rule modification should allow to easily change all the
values, warn if time rules is shared, and also have an easy way to
'disconnect' the time rule, i.e. make a copy of it and edit only the new copy
(instead of the shared original).
All these are user interface things not affecting the low-level stuff.
Maybe you should sat down with some UX designer, talk about these cases and
draw some hand-made pictures.
I do not believe that this will require any changes in schema so you can
polish SSSD and framework implementation in meantime.
> On the link below is a PROTOTYPE-patched FreeIPA that covers most of the CLI
> functionality (except for the creation of iCalendar strings from options) for
> better illustration of the design.
Honestly I did not look at the code today :-)
Overall, I'm glad to see current proposal. After so many iteration, we reached
something which does not have any glaring problem :-)
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code