On 21.1.2014 10:43, Alexander Bokovoy wrote:
On Tue, 21 Jan 2014, Petr Vobornik wrote:
On 20.1.2014 18:01, Alexander Bokovoy wrote:
On Fri, 17 Jan 2014, Petr Vobornik wrote:
Note: this version of the patch is especially prepared for ipa-3-3

Add Web UI counterpart of following CLI commands:

* trust-fetch-domains Refresh list of the domains associated with the
* trustdomain-del Remove infromation about the domain associated with
the trust.
* trustdomain-disable Disable use of IPA resources by the domain of
the trust
* trustdomain-enable Allow use of IPA resources by the domain of the
* trustdomain-find Search domains of the trust

ACK functionally, everything works for me.

I wonder if you could make UI a bit smarter and prevent enable/disable
actions for the forest root trusted domain. Right now selecting it for
'disable' will show you an error telling that disabling root domain is
not possible.

Some enhancement could be done in this area. Similar "issue" is also
present when enabling/disabling already enabled/disabled items (not
just in trusted domains but also in users, HBAC and SUDO rules... pages).

But what should be the ideal behavior?

We must take into considerations facts as follows:
- button which executes the action is enabled/disabled based on user
- user can select multiple items
- some of those items are suitable for the action (e.g., disabled
items for enable action), some not (disabled for disable).
- backend will tell us what succeeded and what not

Current behavior:
- action button is enabled when user selects any item
- after action execution, user is told, if some or all items were not
suitable (the action was not performed for them).

If server behaves correctly this UI behavior should not cause any harm.

Some possible enhancements are:
1. Do not enable action button if all selected items are not suitable
for the action. If some are suitable, continue with current behavior

2. If some of selected items are not suitable, show a warning dialog
which will list items for which the action will be executed and items
for which it won't be. After confirmation, request will be sent only
with suitable items.

3. Do not enable action button if some selected item is not suitable.

#1 and #2 can be combined. I'm not a fan of #3; sounds more like a

Do you have something similar in mind?
#1 and #2 would require either embedding knowledge about specific items
in Web
UI or extending metadata we have about commands. In both cases it looks
a bit weird as it is not a metadata per se. I'm not even sure we can
maintain it properly in all cases.

Anyway I don't think this is a material for IPA 3.3. If you agree, I
will open a new ticket and also ask Kyle for his option on this topic.
Yes, it is something for future but given options you presented I don't
see much future in it...

It's feasible. For standard enable/disable it could more or less declarative. The "root domain" case will require more embedding of specific logic. I guess it's OK, not everything can/should be driven by metadata.

Anyway here's a ticket https://fedorahosted.org/freeipa/ticket/4129 (beer exchange candidate)
Petr Vobornik

Freeipa-devel mailing list

Reply via email to