Re: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View
On Mon, 20 Oct 2014, Endi Sukma Dewata wrote: On 10/17/2014 4:55 PM, Petr Vobornik wrote: On 17.10.2014 22:51, Endi Sukma Dewata wrote: On 10/10/2014 6:44 AM, Petr Vobornik wrote: Web UI part of: https://fedorahosted.org/freeipa/ticket/4615 Patch 767 is a little refactoring needed for $pre_op(as plain object) work as intended even with instantiated objects + fixes a bug where Evented objects were not considered a framework object. Patch 768 switches tabs so we can hide it later Patch 769 hides the tab PAtch 770 is not really needed(would like to hear options whether to include it). It's in effect only if user somehow manages to open 'Applies to hosts' facet for 'Default trust view'. Maybe redirection would be better - if we need to act. For some reason I don't see the Default Trust View in the database/CLI/UI with a brand new server installation. Alexander said he will investigate on Monday. The patches seem to be fine, I don't have any objections, feel free to push. The missing Default Trust View is most likely unrelated to UI. It should be added when you run ipa-adtrust-install. OK, that fixed it. Some comments: 1. Shouldn't the Default Trust View entry be added during the initial installation? Although it's unlikely to conflict with user-defined entries, it's kind of strange to add a 'built-in' entry after the initial installation. It only can contain entries from the trusted domains. Adding it before we can serve trusted domains, i.e. before ipa-adtrust-install, makes it more complicated as users will not be able to add overrides to it. On the other hand, users will not be able to add entries there until actual trust is created so may be adding it as part of default configuration, even before ipa-adtrust-install isn't a big issue at all, if we would provide proper help/hint message. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View
On 10/20/2014 08:09 AM, Alexander Bokovoy wrote: On Mon, 20 Oct 2014, Endi Sukma Dewata wrote: On 10/17/2014 4:55 PM, Petr Vobornik wrote: On 17.10.2014 22:51, Endi Sukma Dewata wrote: On 10/10/2014 6:44 AM, Petr Vobornik wrote: Web UI part of: https://fedorahosted.org/freeipa/ticket/4615 Patch 767 is a little refactoring needed for $pre_op(as plain object) work as intended even with instantiated objects + fixes a bug where Evented objects were not considered a framework object. Patch 768 switches tabs so we can hide it later Patch 769 hides the tab PAtch 770 is not really needed(would like to hear options whether to include it). It's in effect only if user somehow manages to open 'Applies to hosts' facet for 'Default trust view'. Maybe redirection would be better - if we need to act. For some reason I don't see the Default Trust View in the database/CLI/UI with a brand new server installation. Alexander said he will investigate on Monday. The patches seem to be fine, I don't have any objections, feel free to push. The missing Default Trust View is most likely unrelated to UI. It should be added when you run ipa-adtrust-install. OK, that fixed it. Some comments: 1. Shouldn't the Default Trust View entry be added during the initial installation? Although it's unlikely to conflict with user-defined entries, it's kind of strange to add a 'built-in' entry after the initial installation. It only can contain entries from the trusted domains. Adding it before we can serve trusted domains, i.e. before ipa-adtrust-install, makes it more complicated as users will not be able to add overrides to it. On the other hand, users will not be able to add entries there until actual trust is created so may be adding it as part of default configuration, even before ipa-adtrust-install isn't a big issue at all, if we would provide proper help/hint message. I think the reasoning behind adding it as part of adtrust-install was the following scenario, which can happen for IPA installs without adtrust component. 1.) User installs IPA 2.) Tries to override some IPA users 3.) Sees Default Trust View and is confused, since he has no trusts or no AD in his environment We actually add more built-in entries during the adtrust-install, e.g. Default SMB group. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View
On 20.10.2014 07:51, Endi Sukma Dewata wrote: On 10/17/2014 4:55 PM, Petr Vobornik wrote: On 17.10.2014 22:51, Endi Sukma Dewata wrote: On 10/10/2014 6:44 AM, Petr Vobornik wrote: Web UI part of: https://fedorahosted.org/freeipa/ticket/4615 2. The description field in the Settings page for Default Trust View should be read-only since the entry cannot be modified. 3. The Delete action in the Settings page for Default Trust View should not exist since the entry cannot be deleted. Probably the Actions drop-down list can be disabled. wrt #2, #3, I wish that one day it will be reflected in attributelevelrights and entrylevelrights. Or rather API equivalents since these two are very LDAP specific. 4. I think this was discussed before, but I'm just not sure what the plan is. The current facet tab titles seem to be redundant since we already have facet group headers that say ID view overrides/applies to. Are we going to change User/Group ID overrides into Users/Groups and Applied to hosts into Hosts? Neglection from my part. The tab labels were not changed after adding of tab group label. https://fedorahosted.org/freeipa/ticket/4650 No major issue. ACK. Pushed to master: * 896d47c92f9e7f8322456b68b767bf78f0897b0a webui: make Evented a part of base IPA.object * 2e27f1ee69761b147fba50337424acabfd065a93 webui: change order of idview's facet groups * d3f46d4e78cd871b4ab951d57ce309cd9997bea1 webui: hide applied to hosts tab for Default Trust View * 01a9e7ef9e58e14fdb362bdd61b22d667d773052 webui: hide (un)apply buttons for Default Trust View ipa-4-1: * b05f39510cf38f837fa2ae64ff13692b19f4895e webui: make Evented a part of base IPA.object * 2046470be501af10c5901838b9fc6fba93017d38 webui: change order of idview's facet groups * 04a3dad96d60a422cf11486bf788262931d00c2f webui: hide applied to hosts tab for Default Trust View * 3485c6e689eb93184704287b678dbe07135cc46f webui: hide (un)apply buttons for Default Trust View -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View
On Mon, 20 Oct 2014, Tomas Babej wrote: On 10/20/2014 08:09 AM, Alexander Bokovoy wrote: On Mon, 20 Oct 2014, Endi Sukma Dewata wrote: On 10/17/2014 4:55 PM, Petr Vobornik wrote: On 17.10.2014 22:51, Endi Sukma Dewata wrote: On 10/10/2014 6:44 AM, Petr Vobornik wrote: Web UI part of: https://fedorahosted.org/freeipa/ticket/4615 Patch 767 is a little refactoring needed for $pre_op(as plain object) work as intended even with instantiated objects + fixes a bug where Evented objects were not considered a framework object. Patch 768 switches tabs so we can hide it later Patch 769 hides the tab PAtch 770 is not really needed(would like to hear options whether to include it). It's in effect only if user somehow manages to open 'Applies to hosts' facet for 'Default trust view'. Maybe redirection would be better - if we need to act. For some reason I don't see the Default Trust View in the database/CLI/UI with a brand new server installation. Alexander said he will investigate on Monday. The patches seem to be fine, I don't have any objections, feel free to push. The missing Default Trust View is most likely unrelated to UI. It should be added when you run ipa-adtrust-install. OK, that fixed it. Some comments: 1. Shouldn't the Default Trust View entry be added during the initial installation? Although it's unlikely to conflict with user-defined entries, it's kind of strange to add a 'built-in' entry after the initial installation. It only can contain entries from the trusted domains. Adding it before we can serve trusted domains, i.e. before ipa-adtrust-install, makes it more complicated as users will not be able to add overrides to it. On the other hand, users will not be able to add entries there until actual trust is created so may be adding it as part of default configuration, even before ipa-adtrust-install isn't a big issue at all, if we would provide proper help/hint message. I think the reasoning behind adding it as part of adtrust-install was the following scenario, which can happen for IPA installs without adtrust component. 1.) User installs IPA 2.) Tries to override some IPA users 3.) Sees Default Trust View and is confused, since he has no trusts or no AD in his environment Even after ipa-adtrust-install run you would still not be able to resolve AD users unless trust is added. It does not mean we should move creating 'Default Trust View' to the first trust. What about filtering out 'Default Trust View' if no trusts are in place? This would be a bit problematic for the case when you had trusts and deleted them and currently have none of them but overrides are in place, but at least it would be consistent -- you don't see default view and you are not able to add there anything. However, it raises another question: if no trusts exist right now but there are some AD user overrides in any view, how would we display them? We cannot resolve SIDs to names at this point so overrides will look ugly anyway. We can use ipaOriginalUid for users but we don't have anything like that for groups. We actually add more built-in entries during the adtrust-install, e.g. Default SMB group. We don't use these entries in the UI, so they don't create any specific issue. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View
On 10/20/2014 12:30 PM, Alexander Bokovoy wrote: On Mon, 20 Oct 2014, Tomas Babej wrote: On 10/20/2014 08:09 AM, Alexander Bokovoy wrote: On Mon, 20 Oct 2014, Endi Sukma Dewata wrote: On 10/17/2014 4:55 PM, Petr Vobornik wrote: On 17.10.2014 22:51, Endi Sukma Dewata wrote: On 10/10/2014 6:44 AM, Petr Vobornik wrote: Web UI part of: https://fedorahosted.org/freeipa/ticket/4615 Patch 767 is a little refactoring needed for $pre_op(as plain object) work as intended even with instantiated objects + fixes a bug where Evented objects were not considered a framework object. Patch 768 switches tabs so we can hide it later Patch 769 hides the tab PAtch 770 is not really needed(would like to hear options whether to include it). It's in effect only if user somehow manages to open 'Applies to hosts' facet for 'Default trust view'. Maybe redirection would be better - if we need to act. For some reason I don't see the Default Trust View in the database/CLI/UI with a brand new server installation. Alexander said he will investigate on Monday. The patches seem to be fine, I don't have any objections, feel free to push. The missing Default Trust View is most likely unrelated to UI. It should be added when you run ipa-adtrust-install. OK, that fixed it. Some comments: 1. Shouldn't the Default Trust View entry be added during the initial installation? Although it's unlikely to conflict with user-defined entries, it's kind of strange to add a 'built-in' entry after the initial installation. It only can contain entries from the trusted domains. Adding it before we can serve trusted domains, i.e. before ipa-adtrust-install, makes it more complicated as users will not be able to add overrides to it. On the other hand, users will not be able to add entries there until actual trust is created so may be adding it as part of default configuration, even before ipa-adtrust-install isn't a big issue at all, if we would provide proper help/hint message. I think the reasoning behind adding it as part of adtrust-install was the following scenario, which can happen for IPA installs without adtrust component. 1.) User installs IPA 2.) Tries to override some IPA users 3.) Sees Default Trust View and is confused, since he has no trusts or no AD in his environment Even after ipa-adtrust-install run you would still not be able to resolve AD users unless trust is added. It does not mean we should move creating 'Default Trust View' to the first trust. What about filtering out 'Default Trust View' if no trusts are in place? This would be a bit problematic for the case when you had trusts and deleted them and currently have none of them but overrides are in place, but at least it would be consistent -- you don't see default view and you are not able to add there anything. However, it raises another question: if no trusts exist right now but there are some AD user overrides in any view, how would we display them? We cannot resolve SIDs to names at this point so overrides will look ugly anyway. We can use ipaOriginalUid for users but we don't have anything like that for groups. I think we should fail in the trust-del if there are any overrides tied to this particular trust, unless --forced (which should be used only for recreation of the trust). Currently, we rely on resolving the user/group name to do any operation on the ID override, so having the trust removed, you'd have to use LDAP directly to remove the entries. We actually add more built-in entries during the adtrust-install, e.g. Default SMB group. We don't use these entries in the UI, so they don't create any specific issue. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View
On Mon, 20 Oct 2014, Tomas Babej wrote: What about filtering out 'Default Trust View' if no trusts are in place? This would be a bit problematic for the case when you had trusts and deleted them and currently have none of them but overrides are in place, but at least it would be consistent -- you don't see default view and you are not able to add there anything. However, it raises another question: if no trusts exist right now but there are some AD user overrides in any view, how would we display them? We cannot resolve SIDs to names at this point so overrides will look ugly anyway. We can use ipaOriginalUid for users but we don't have anything like that for groups. I think we should fail in the trust-del if there are any overrides tied to this particular trust, unless --forced (which should be used only for recreation of the trust). I'd love to see a mass-removal tool per trusted domain then. Also, removing trust does not mean overrides become invalid, only that they become not editable or visible. They will not be enforced because trust is not in place anyway. Currently, we rely on resolving the user/group name to do any operation on the ID override, so having the trust removed, you'd have to use LDAP directly to remove the entries. It should be fine to remove the trust, just that our code should be able to deal with domain SIDs for mass removal of ID overrides. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View
On 10/17/2014 4:55 PM, Petr Vobornik wrote: On 17.10.2014 22:51, Endi Sukma Dewata wrote: On 10/10/2014 6:44 AM, Petr Vobornik wrote: Web UI part of: https://fedorahosted.org/freeipa/ticket/4615 Patch 767 is a little refactoring needed for $pre_op(as plain object) work as intended even with instantiated objects + fixes a bug where Evented objects were not considered a framework object. Patch 768 switches tabs so we can hide it later Patch 769 hides the tab PAtch 770 is not really needed(would like to hear options whether to include it). It's in effect only if user somehow manages to open 'Applies to hosts' facet for 'Default trust view'. Maybe redirection would be better - if we need to act. For some reason I don't see the Default Trust View in the database/CLI/UI with a brand new server installation. Alexander said he will investigate on Monday. The patches seem to be fine, I don't have any objections, feel free to push. The missing Default Trust View is most likely unrelated to UI. It should be added when you run ipa-adtrust-install. OK, that fixed it. Some comments: 1. Shouldn't the Default Trust View entry be added during the initial installation? Although it's unlikely to conflict with user-defined entries, it's kind of strange to add a 'built-in' entry after the initial installation. 2. The description field in the Settings page for Default Trust View should be read-only since the entry cannot be modified. 3. The Delete action in the Settings page for Default Trust View should not exist since the entry cannot be deleted. Probably the Actions drop-down list can be disabled. 4. I think this was discussed before, but I'm just not sure what the plan is. The current facet tab titles seem to be redundant since we already have facet group headers that say ID view overrides/applies to. Are we going to change User/Group ID overrides into Users/Groups and Applied to hosts into Hosts? No major issue. ACK. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View
On 10/10/2014 6:44 AM, Petr Vobornik wrote: Web UI part of: https://fedorahosted.org/freeipa/ticket/4615 Patch 767 is a little refactoring needed for $pre_op(as plain object) work as intended even with instantiated objects + fixes a bug where Evented objects were not considered a framework object. Patch 768 switches tabs so we can hide it later Patch 769 hides the tab PAtch 770 is not really needed(would like to hear options whether to include it). It's in effect only if user somehow manages to open 'Applies to hosts' facet for 'Default trust view'. Maybe redirection would be better - if we need to act. For some reason I don't see the Default Trust View in the database/CLI/UI with a brand new server installation. Alexander said he will investigate on Monday. The patches seem to be fine, I don't have any objections, feel free to push. The missing Default Trust View is most likely unrelated to UI. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View
On 17.10.2014 22:51, Endi Sukma Dewata wrote: On 10/10/2014 6:44 AM, Petr Vobornik wrote: Web UI part of: https://fedorahosted.org/freeipa/ticket/4615 Patch 767 is a little refactoring needed for $pre_op(as plain object) work as intended even with instantiated objects + fixes a bug where Evented objects were not considered a framework object. Patch 768 switches tabs so we can hide it later Patch 769 hides the tab PAtch 770 is not really needed(would like to hear options whether to include it). It's in effect only if user somehow manages to open 'Applies to hosts' facet for 'Default trust view'. Maybe redirection would be better - if we need to act. For some reason I don't see the Default Trust View in the database/CLI/UI with a brand new server installation. Alexander said he will investigate on Monday. The patches seem to be fine, I don't have any objections, feel free to push. The missing Default Trust View is most likely unrelated to UI. It should be added when you run ipa-adtrust-install. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View
Web UI part of:
https://fedorahosted.org/freeipa/ticket/4615
Patch 767 is a little refactoring needed for $pre_op(as plain object)
work as intended even with instantiated objects + fixes a bug where
Evented objects were not considered a framework object.
Patch 768 switches tabs so we can hide it later
Patch 769 hides the tab
PAtch 770 is not really needed(would like to hear options whether to
include it). It's in effect only if user somehow manages to open
'Applies to hosts' facet for 'Default trust view'. Maybe redirection
would be better - if we need to act.
--
Petr Vobornik
From 1f70f5ebaed8ce52617341a7c8e826923b09030a Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Fri, 10 Oct 2014 10:50:35 +0200
Subject: [PATCH] webui: hide (un)apply buttons for Default Trust View
---
install/ui/src/freeipa/idviews.js | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/install/ui/src/freeipa/idviews.js b/install/ui/src/freeipa/idviews.js
index 39424ef3e1e716a1e902a2580fa5fd57b0426371..ee522467501986116c759ef7150db294b9e34157 100644
--- a/install/ui/src/freeipa/idviews.js
+++ b/install/ui/src/freeipa/idviews.js
@@ -185,7 +185,17 @@ return {
target_entity: 'host',
target_facet: 'details'
}
-]
+],
+state: {
+evaluators: [
+{
+$factory: mod_details.value_state_evaluator,
+attribute: 'cn',
+value: idviews.DEFAULT_TRUST_VIEW,
+representation: 'cn_default_trust_view'
+}
+]
+}
}
],
@@ -395,6 +405,7 @@ idviews.apply_action = function(spec) {
spec = spec || {};
spec.name = spec.name || 'idview_apply';
spec.label = spec.label || '@i18n:objects.idview.apply_hosts';
+spec.hide_cond = spec.hide_cond || ['cn_default_trust_view'];
var that = IPA.action(spec);
--
1.9.3
From 10fe2a4e62c4b2423b580d559260da57ca8c9870 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Fri, 10 Oct 2014 10:49:43 +0200
Subject: [PATCH] webui: hide applied to hosts tab for Default Trust View
because applying Default Trust view on hosts is not allowed
https://fedorahosted.org/freeipa/ticket/4615
---
install/ui/src/freeipa/facet.js | 5 -
install/ui/src/freeipa/idviews.js | 26 +-
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/install/ui/src/freeipa/facet.js b/install/ui/src/freeipa/facet.js
index 556b17fe71f6a1eb460d40ce76746f868d0791ae..43627d9d531ed700ff780a0773451eaf17b1cbdd 100644
--- a/install/ui/src/freeipa/facet.js
+++ b/install/ui/src/freeipa/facet.js
@@ -211,7 +211,8 @@ exp.facet = IPA.facet = function(spec, no_init) {
* Facet header
* @property {facet.facet_header}
*/
-that.header = spec.header || IPA.facet_header({ facet: that });
+that.header = builder.build('', spec.header || {}, {},
+{ $pre_ops: [{ facet: that }], $factory: IPA.facet_header });
/**
* Hard override for `needs_update()` logic. When set, `needs_update`
@@ -1400,6 +1401,8 @@ exp.facet_header = IPA.facet_header = function(spec) {
that.load();
};
+that.facet_header_set_pkey = that.set_pkey;
+
return that;
};
diff --git a/install/ui/src/freeipa/idviews.js b/install/ui/src/freeipa/idviews.js
index a95806283225c0ab6d064b182df285e755637d04..39424ef3e1e716a1e902a2580fa5fd57b0426371 100644
--- a/install/ui/src/freeipa/idviews.js
+++ b/install/ui/src/freeipa/idviews.js
@@ -37,7 +37,9 @@ define([
* @class
* @singleton
*/
-var idviews = IPA.idviews = {};
+var idviews = IPA.idviews = {
+DEFAULT_TRUST_VIEW: 'Default Trust View'
+};
var make_spec = function() {
return {
@@ -82,6 +84,7 @@ return {
},
{
$type: 'details',
+header: idviews.idview_facet_header,
actions: [
'delete'
],
@@ -104,6 +107,7 @@ return {
{
$type: 'nested_search',
facet_group: 'overrides',
+header: idviews.idview_facet_header,
nested_entity: 'idoverrideuser',
search_all_entries: true,
label: '@mo:idoverrideuser.label',
@@ -123,6 +127,7 @@ return {
{
$type: 'nested_search',
facet_group: 'overrides',
+header: idviews.idview_facet_header,
nested_entity: 'idoverridegroup',
search_all_entries: true,
label: '@mo:idoverridegroup.label',
@@ -360,6 +365,25 @@ idviews.appliedtohosts_facet = function(spec, no_init) {
return that;
};
+idviews.idview_facet_header = function(spec) {
+
+var that = mod_facet.facet_header(spec);
+
+/**
+ * Set pkeys and hides 'appliedtohosts' facet for 'Default Trust View'
+ * @param {string}
