Re: [Freeipa-devel] [PATCH] 297 Fixed enroll labels.
On 10/26/2011 07:44 PM, Endi Sukma Dewata wrote: On 10/26/2011 7:09 AM, Petr Vobornik wrote: 1) add_dialog was renamed to entity_adder_dialog but its method add_dialog_create wasn't renamed Fixed. ACK -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 300 Refactored validation code.
On 10/26/2011 08:09 PM, Endi Sukma Dewata wrote: The validation code in details facet, dialog, and sections have been modified to work more consistently. This is required by patch #301. ACK -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 301 Added password field in user adder dialog.
On 10/26/2011 08:11 PM, Endi Sukma Dewata wrote:
The user adder dialog has been modified to provide optional fields
to specify password during user creation.
Ticket #1646
1) message in: 'field2.show_error('Passwords do not match');' should
use translated string.
--
Petr Vobornik
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 900 fix users in nis netgroup
On Wed, 2011-10-26 at 18:06 -0400, Rob Crittenden wrote: Users weren't appearing in ypcat output in the netgroup map due to a syntax error. This patch should fix new and existing installations. rob ACK. Works great for both update and new installations. Pushed to master, ipa-2-1. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 302 Fixed inconsistent image names.
On 10/27/2011 12:31 AM, Endi Sukma Dewata wrote: The images have been renamed to be more consistent and moved into the images directory to mimic the original jQuery UI structure. Ticket #1613 ACK -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 156 Create pkey-only option for find commands
On Wed, 2011-10-26 at 14:07 -0500, Endi Sukma Dewata wrote: On 10/26/2011 1:43 PM, Martin Kosek wrote: I think we probably need 2 different size limits: one for regular queries (set on LDAP server) and the other for pulling primary keys (maintained by IPA server). Suppose we have a system with 5000 users, we need to be able to pull all 5000 primary keys. But for regular queries we probably still want to keep a smaller limit. This is true, but I am not sure how can we help on server side with this. Limits are something that CLI user or Web UI should control via --sizelimit and --timelimit parameters and the config-mod setting I referred to. Can you use --pkey-only, --sizelimit and --timelimit parameters to manage large data sets in WebUI or would you need another tweak? The UI can add a --sizelimit param with a bigger limit, but if the limit is stored in the UI it will be static. The UI can provide an interface to change it but it's only temporary and specific to one browser. What we can do is to make sure that all our *-find commands have --sizelimit and --timelimit parameters. I see that for example delegation-find does not have one. I think it's better to store this limit on the server. When the server receives a *-find command with --pkey-only it will add this size limit by default. IIUC your idea is to have 2 new config-mod options like this: # ipa config-show --all ... Search time limit: 2 Search size limit: 100 Search time limit with pkey-only: 10 Search size limit with pkey-only: 5000 Hm, I am still not sold for this behavior. I don't think that user would expect that when he asks for smaller data package via --pkey-only we would silently undercover change --sizelimit and --timelimit parameters to different value than he is used to. I would you a second opinion on this. Rob? Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 303 Fixed inconsistent details facet validation.
On 10/27/2011 01:39 AM, Endi Sukma Dewata wrote: The details facet validation has been moved out of update() such that all subclasses perform consistent validation. Ticket #1455 ACK with a small doubt. I'm not sure if moving the validation call to update button's click handler is the right move. I think, this way the handler is doing more things than it should do. However I'm fond of changing the update method to be more override friendly. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 029 Page is cleared before it is visible
https://fedorahosted.org/freeipa/ticket/1459
Changes:
* added clear method to widgets, section, search, details, association
facets
* clear method in facet is called only if key/filter was changed
--
Petr Vobornik
From 22d6ba37f74ec40a8223082b8f6869ec9f1155a5 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Mon, 24 Oct 2011 14:53:29 +0200
Subject: [PATCH] Page is cleared before it is visible
https://fedorahosted.org/freeipa/ticket/1459
Changes:
* added clear method to widgets, section, search, details, association facets
* clear method in facet is called only if key/filter was changed
---
install/ui/association.js | 11 ++
install/ui/certificate.js |9
install/ui/details.js | 23 +
install/ui/host.js| 12 +++
install/ui/search.js | 11 ++
install/ui/service.js |5
install/ui/user.js|5
install/ui/widget.js | 48 +
8 files changed, 124 insertions(+), 0 deletions(-)
diff --git a/install/ui/association.js b/install/ui/association.js
index ebb6e421ff3b8538116471de240b1f972e08e6bf..f7e397c92fb97e0a3b1552f29bb3af9da6a55756 100644
--- a/install/ui/association.js
+++ b/install/ui/association.js
@@ -1198,9 +1198,20 @@ IPA.association_facet = function (spec) {
command.on_error = that.on_error;
+var old_pkey = that.old_pkey;
+that.old_pkey = pkey;
+
+if (!old_pkey || old_pkey[0] !== pkey[0]) {
+that.clear();
+}
+
command.execute();
};
+that.clear = function() {
+that.table.clear();
+};
+
/*initialization*/
var adder_columns = spec.adder_columns || [];
for (var i=0; iadder_columns.length; i++) {
diff --git a/install/ui/certificate.js b/install/ui/certificate.js
index 6136edaf0bbcedac890c8c8a6df3297d6802ccc9..70fc1ba3545a5339f873f47cc7656a0953fb50fd 100755
--- a/install/ui/certificate.js
+++ b/install/ui/certificate.js
@@ -725,6 +725,15 @@ IPA.cert.status_widget = function(spec) {
}
};
+that.clear = function() {
+that.status_valid.css('display', 'none');
+that.status_missing.css('display', 'none');
+that.status_revoked.css('display', 'none');
+that.revoke_button.css('display', 'none');
+that.restore_button.css('display', 'none');
+that.revocation_reason.text('');
+};
+
function set_status(status, revocation_reason) {
that.status_valid.css('display', status == IPA.cert.CERTIFICATE_STATUS_VALID ? 'inline' : 'none');
that.status_missing.css('display', status == IPA.cert.CERTIFICATE_STATUS_MISSING ? 'inline' : 'none');
diff --git a/install/ui/details.js b/install/ui/details.js
index 5c03de0a32aed46aaebd36facddceaf56a853004..a863c18289c2df45aaecec0a68f464c5dc591bf8 100644
--- a/install/ui/details.js
+++ b/install/ui/details.js
@@ -201,6 +201,14 @@ IPA.details_section = function(spec) {
}
};
+that.clear = function() {
+var fields = that.fields.values;
+
+for (var i=0; i fields.length; i++) {
+fields[i].clear();
+}
+};
+
init();
// methods that should be invoked by subclasses
@@ -720,9 +728,24 @@ IPA.details_facet = function(spec) {
that.pre_execute_hook(command);
}
+var old_pkey = that.old_pkey;
+that.old_pkey = that.pkey;
+
+if (that.pkey !== old_pkey) {
+that.clear();
+}
+
command.execute();
};
+that.clear = function() {
+var sections = that.sections.values;
+
+for (var i=0; i sections.length; i++) {
+sections[i].clear();
+}
+};
+
that.add_sections(spec.sections);
that.details_facet_create_content = that.create_content;
diff --git a/install/ui/host.js b/install/ui/host.js
index 4c0ce6ed0e461a38a565c1450cd483098b0c2dc7..ba28ebcf8ce3f176fcab06616733ae07ef36c976 100644
--- a/install/ui/host.js
+++ b/install/ui/host.js
@@ -567,6 +567,11 @@ IPA.host_keytab_widget = function(spec) {
set_status(value ? 'present' : 'missing');
};
+that.clear = function() {
+that.present_span.css('display', 'none');
+that.missing_span.css('display', 'none');
+};
+
function set_status(status) {
that.present_span.css('display', status == 'present' ? 'inline' : 'none');
that.missing_span.css('display', status == 'missing' ? 'inline' : 'none');
@@ -720,6 +725,13 @@ IPA.host_password_widget = function(spec) {
set_status(value ? 'present' : 'missing');
};
+that.clear = function() {
+that.missing_span.css('display', 'none');
+that.present_span.css('display', 'none');
+var password_label = $('.button-label', that.set_password_button);
+password_label.text('');
+};
+
function set_status(status) {
that.status = status;
diff
[Freeipa-devel] [PATCH] 56 Add new Param method for marshalling values from complex data types
Add new Param method for marshalling values from complex data types to
primitive data types suitable for transmission over RPC.
This change makes it possible to use complex data types (like
python-netaddr IPAddress) in parameters.
https://fedorahosted.org/freeipa/ticket/2033
This will help implementing IP address parameter types properly in
https://fedorahosted.org/freeipa/ticket/1487 .
--
Jan Cholasta
From 861748ce6c47d6e7852e19c5f862393a1b287c26 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Wed, 26 Oct 2011 11:26:30 -0400
Subject: [PATCH] Add new Param method for marshalling values from complex
data types to primitive data types suitable for
transmission over RPC.
This change makes it possible to use complex data types in parameters.
ticket 2033
---
ipalib/frontend.py | 17 +
ipalib/parameters.py | 19 +++
ipalib/plugins/dns.py|4 +++-
tests/test_ipalib/test_frontend.py | 13 +
tests/test_ipalib/test_parameters.py | 33 +
5 files changed, 81 insertions(+), 5 deletions(-)
diff --git a/ipalib/frontend.py b/ipalib/frontend.py
index 61e7f49..a864c2d 100644
--- a/ipalib/frontend.py
+++ b/ipalib/frontend.py
@@ -565,6 +565,8 @@ class Command(HasParam):
return newdict
def __attributes_2_entry(self, kw):
+kw = self.marshal(**kw)
+
for name in self.params:
if self.params[name].attribute and name in kw:
value = kw[name]
@@ -648,10 +650,14 @@ class Command(HasParam):
(k, self.params[k].convert(v)) for (k, v) in kw.iteritems()
)
-def __convert_iter(self, kw):
-for param in self.params():
-if kw.get(param.name, None) is None:
-continue
+def marshal(self, **kw):
+
+Return a dictionary of marshalled values.
+
+for (name, value) in kw.iteritems():
+if name in self.params:
+kw[name] = self.params[name].marshal(value)
+return kw
def get_default(self, **kw):
@@ -757,6 +763,9 @@ class Command(HasParam):
Forward call over XML-RPC to this same command on server.
+params = self.args_options_2_params(*args, **kw)
+params = self.marshal(**params)
+(args, kw) = self.params_2_args_options(**params)
return self.Backend.xmlclient.forward(self.name, *args, **kw)
def finalize(self):
diff --git a/ipalib/parameters.py b/ipalib/parameters.py
index f9e171b..85f9591 100644
--- a/ipalib/parameters.py
+++ b/ipalib/parameters.py
@@ -717,6 +717,25 @@ class Param(ReadOnly):
error=ugettext(self.type_error),
)
+def marshal(self, value):
+
+Marshal ``value`` to a primitive data type, suitable for transmission.
+
+if value is None:
+return None
+if self.multivalue:
+return tuple(self._marshal_scalar(v, i) for (i, v) in enumerate(value))
+else:
+return self._marshal_scalar(value)
+
+def _marshal_scalar(self, value, index=None):
+
+Marshal a single scalar value.
+
+if not isinstance(value, (int, long, bool, float, str, unicode)):
+raise TypeError('value: must be primitive type, not %s' % type(value).__name__)
+return value
+
def validate(self, value, context=None):
Check validity of ``value``.
diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
index 97eb6a6..545e33b 100644
--- a/ipalib/plugins/dns.py
+++ b/ipalib/plugins/dns.py
@@ -518,7 +518,7 @@ class dnszone_find(LDAPSearch):
if 'idnsname' not in options:
options['idnsname'] = self.obj.params['idnsname'].get_default(**options)
del options['name_from_ip']
-return super(dnszone_find, self).args_options_2_entry(self, *args, **options)
+return super(dnszone_find, self).args_options_2_entry(*args, **options)
takes_options = LDAPSearch.takes_options + (
Flag('forward_only',
@@ -713,6 +713,7 @@ class dnsrecord_cmd_w_record_options(Command):
yield self.get_record_option(t)
def record_options_2_entry(self, **options):
+options = self.marshal(**options)
entries = dict((t, options.get(t, [])) for t in _record_attributes)
entries.update(dict((k, []) for (k,v) in entries.iteritems() if v == None ))
return entries
@@ -900,6 +901,7 @@ class dnsrecord_mod(dnsrecord_mod_record):
old_entry_attrs[a] = v
def record_options_2_entry(self, **options):
+options = self.marshal(**options)
entries = dict((t, options.get(t, [])) for t in _record_attributes)
return has_cli_options(entries, self.no_option_msg, True)
diff --git a/tests/test_ipalib/test_frontend.py
Re: [Freeipa-devel] [PATCH] 880 don't check for existing 389-ds instances
On Fri, 2011-10-21 at 15:29 -0400, Rob Crittenden wrote: Rob Crittenden wrote: We don't need to prohibit existing 389-ds instances when installing IPA, just that the ports we need are available. Remove this check. For master only. rob Re-based patch against master. rob Works ok, I was able to install IPA server next to other dirsrv sitting on another port. The installation could get to trouble if another DS would sit on a standard port but would be stopped at the moment, i.e. ports 389 and 636 would be free. But I think this is a risk we can take. My only concern is with uninstallation - we shutdown all dirsrv instances during the process. Thus, in the end the custom dirsrv instance remains stopped. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] ipalib vs. ipapython?
Adam Young wrote: On 10/25/2011 05:24 PM, John Dennis wrote: Usually when I look at a source code directory layout it's fairly obvious what belongs in each directory. I'll be honest, I've never quite understood the role of ipapython vs. ipalib. From time to time I have to do some code refactoring, especially in the context of introducing common code meant to be shared across a variety of places in the code base. So what is the role of ipalib vs. ipapython? What are their intended purposes? What guidelines should be followed when determining where shared code is located? John Agreed. I've had this confusion myself. I would expect as an outsider that ipalib would be an ELF, and that ipapython would be the bindings to it. I know the project well enough to understand why that is not the case. We have 3 distinct deployment scenarios: server with admin client without admin client with admin. [ayoung@ayoung freeipa]$ rpm -q --whatrequires freeipa-python freeipa-client-2.1.1-1.fc15.x86_64 freeipa-admintools-2.1.1-1.fc15.x86_64 freeipa-server-2.1.1-1.fc15.x86_64 client and admintool both depend on freeipa-python server requires pretty much everything so it seems we should really only have 4 packages: server, client, admintools, and python. I think what Martin was saying is that we distinguish between the pieces for install and ldap manipulation from the pieces used for ongoing operations, but that seems like an artificial distinction. The breakdown is more framework vs non-framework. There are a lot of routines in ipapython independent of the framework: the config backup/restore handling, nss routines, dogtag routines, running command-line programs, etc. There is still an outside goal of being able to make the framework usable in other projects. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 028 Code cleanup of HBAC, Sudo rules
I'll rebase this patch on recent patches (which will be soon pushed).
This effort is doing too many things, I'll split the patch into several.
On 10/25/2011 07:57 PM, Endi Sukma Dewata wrote:
On 10/25/2011 7:49 AM, Petr Vobornik wrote:
2. The set_facet() is added to widget. I don't think we want to make
widget dependent on facet. The facet so far is only used by
IPA.sudo.enable_widget. In IPA.sudo.options_section the facet object is
passed as a parameter in spec.
Are you saying that dependency on facet in ALL widgets is bad and only
in a few is good, or in any is bad?
In general less dependency is better. More dependency will limit its
usage. This is inline with the goal to make purely HTML widget.
But if a widget is meant to be used only with a facet then it's
certainly ok to make it depends on facet. However, the rest should not
become unnecessarily dependent on facet too.
I think it doesn't matter if all is dependant when one is dependant.
Anyway currently all association table widgets are dependant
(association.js:386).
Let's use this as an example. The association table explicitly checks if
the facet is dirty and asks the user whether to update/reset/cancel.
Suppose we want to use this inside a dialog, it will still check whether
the current facet is dirty instead of the dialog itself, which may not
be what we want.
Removed. Using instead: that.entity.get_facet() and
that.entity.get_primary_key().
But still I think it would be better to be able to get container
(facet/dialog) for a widget. As you wrote, that.entity.get_facet() may
not always be what we want.
Btw similar topic could be: How to get current entity's pkey?'.
Dependancy on facet.get_primary_key() or
IPA.nav.get_state(that.entity.name+'-pkey') seems wrong too.
Yes. Ideally we should have a path (REST-style URL) instead of the
current parameter-based URL. We should get the pkey from that path.
From dependency point of view, widgets would be still dependant on the
implementation of navigation (IMHO bad).
But it seems that using entity.get_primary key partially solves the problem.
Maybe it would be better if navigation would inject pkey to entity.
Entity wouldn't be that much dependant on navigation implementation.
3. When updating sudo rule, in the original code the rule is
enabled/disabled after all the modifications are done. In the new code
it's reversed. I'm not sure the importance of the execution order for
this particular situation, but suppose it is, is there a way to maintain
the original order?
I was thinking about a command or widget priority. The 'mod' command
would have some default priority or it would get it from facet. The
commands would be sorted by priority before adding them to batch. This
way we can set exact order in facet update.
It's possible, but managing priority could be problematic if they are
spread out, because we have to know all existing priorities before we
can add a new one.
The priority could be part of update info. As there is a field_info we
can create a command_info: { command, priority }.
The original code uses an ordered list of commands.
Before adding commands to batch_command, array of command_info objects
would joined with 'mod' command with default priority and then sorted by
priority.
If the priority was set on each widget, priority management will be on
facet level, which may be fine. There can be some corner case like
dynamic change of priority.
The order which is implemented now is reflecting the order in HBAC
details facet - there were errors when 'mod' was executed before
clearing associations.
Right, so for certain things the order is important.
4. The IPA.header_widget is not really a widget, it's actually part of
layout. In the current implementation a widget always corresponds to an
attribute, so it will be loaded, saved, etc. Since there is no attribute
name matching the header name currently this is not a problem, but it
can pollute the namespace.
This is part of widget nesting topic. In this manner composite_widget
isn't a proper widget too (it can correspond to several or none
attribute).
Purely html rendering widgets can be separated from attribute widgets,
but it would be nice to have them because they can provide easier form
composing. Without them it would be required to override the create
method (in facet or composite_widget/section) which is sometimes better
but often it creates only code duplication with little added logic.
One other solution is to split widgets into non-visual fields and purely
HTML components. Then in the facet we use separate lists for the fields
and HTML components. The fields will have a reference to the
corresponding HTML components. There can be more HTML components than
fields. But this will require a significant restructuring.
Maybe we can use hybrid solution: html widgets would be simple object
with some properties and create() method. They should not be called
widgets. They would
Re: [Freeipa-devel] [PATCH] 297 Fixed enroll labels.
On 10/27/2011 2:07 AM, Petr Vobornik wrote: ACK Pushed to master. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 299 Merged widget's metadata and param_info.
On 10/27/2011 2:22 AM, Petr Vobornik wrote: ACK Pushed to master. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 302 Fixed inconsistent image names.
On 10/27/2011 3:36 AM, Petr Vobornik wrote: ACK Pushed to master. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 156 Create pkey-only option for find commands
On 10/27/2011 3:39 AM, Martin Kosek wrote: IIUC your idea is to have 2 new config-mod options like this: # ipa config-show --all ... Search time limit: 2 Search size limit: 100 Search time limit with pkey-only: 10 Search size limit with pkey-only: 5000 Hm, I am still not sold for this behavior. I don't think that user would expect that when he asks for smaller data package via --pkey-only we would silently undercover change --sizelimit and --timelimit parameters to different value than he is used to. I would you a second opinion on this. Rob? As discussed in the meeting, for the pkey-only we can rely on the default limits imposed by the LDAP server which should be big enough. The UI will add sizelimit=0 as part of ticket #981. The IPA server doesn't need additional changes. ACK and pushed to master. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 301 Added password field in user adder dialog.
On 10/27/2011 2:58 AM, Petr Vobornik wrote:
1) message in: 'field2.show_error('Passwords do not match');' should use
translated string.
Fixed. I'm considering to move the password fields into a reusable
section, but that will be a separate issue.
--
Endi S. Dewata
From 25309c418ee1d0fd0d5b4bf3884bac8d03748fd8 Mon Sep 17 00:00:00 2001
From: Endi S. Dewata edew...@redhat.com
Date: Tue, 25 Oct 2011 15:52:57 -0500
Subject: [PATCH] Added password field in user adder dialog.
The user adder dialog has been modified to provide optional fields
to specify password during user creation.
Ticket #1646
---
install/ui/dialog.js |1 +
install/ui/user.js | 58 +
2 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/install/ui/dialog.js b/install/ui/dialog.js
index ff64b37cc549d7ea9886dc0d58a8f12267ecb839..73c9b6cc30215f59fa3b4be7976c19fb06914106 100644
--- a/install/ui/dialog.js
+++ b/install/ui/dialog.js
@@ -284,6 +284,7 @@ IPA.dialog = function(spec) {
that.dialog_close = that.close;
that.dialog_save = that.save;
that.dialog_reset = that.reset;
+that.dialog_validate = that.validate;
return that;
};
diff --git a/install/ui/user.js b/install/ui/user.js
index 3ff56cd9d2bc3cfe31c1fa88674060bd4d6a9112..69924429d98b4f6dcf74e32f0c5d72cc67a55062 100644
--- a/install/ui/user.js
+++ b/install/ui/user.js
@@ -139,19 +139,67 @@ IPA.entity_factories.user = function() {
link: link
}).
adder_dialog({
-fields: [
+factory: IPA.user_adder_dialog,
+sections: [
{
-name: 'uid',
-required: false
+fields: [
+{
+name: 'uid',
+required: false
+},
+'givenname',
+'sn'
+]
},
-'givenname',
-'sn'
+{
+fields: [
+{
+name: 'userpassword',
+label: IPA.messages.password.new_password,
+type: 'password'
+},
+{
+name: 'userpassword2',
+label: IPA.messages.password.verify_password,
+type: 'password'
+}
+]
+}
]
});
return builder.build();
};
+IPA.user_adder_dialog = function(spec) {
+
+var that = IPA.entity_adder_dialog(spec);
+
+that.validate = function() {
+var valid = that.dialog_validate();
+
+var field1 = that.get_field('userpassword');
+var field2 = that.get_field('userpassword2');
+
+var password1 = field1.save()[0];
+var password2 = field2.save()[0];
+
+if (password1 !== password2) {
+field2.show_error(IPA.messages.password.password_must_match);
+valid = false;
+}
+
+return valid;
+};
+
+that.save = function(record) {
+that.dialog_save(record);
+delete record.userpassword2;
+};
+
+return that;
+};
+
IPA.user_status_widget = function(spec) {
spec = spec || {};
--
1.7.5.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 301 Added password field in user adder dialog.
On 10/27/2011 04:59 PM, Endi Sukma Dewata wrote:
On 10/27/2011 2:58 AM, Petr Vobornik wrote:
1) message in: 'field2.show_error('Passwords do not match');' should use
translated string.
Fixed. I'm considering to move the password fields into a reusable
section, but that will be a separate issue.
ACK
--
Petr Vobornik
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 303 Fixed inconsistent details facet validation.
On 10/27/2011 4:29 AM, Petr Vobornik wrote: ACK with a small doubt. I'm not sure if moving the validation call to update button's click handler is the right move. I think, this way the handler is doing more things than it should do. However I'm fond of changing the update method to be more override friendly. I pushed this to master for now, but I agree with your concern. Suppose there are other buttons that need to do similar operation (like in entity adder dialog) they will need to repeat the same code. We probably can refactor it into a new function that calls validate() and update(). I also think we can move save() outside of update() too, and probably use the result for validation and update instead of calling it multiple times. This will require some more thinking, so let's do it separately. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Extending the IPA-API
We had a pretty good discussion about the apporach we are looking at to
allow end sites to extend their IPA implementations without getting in
the way of upgrades etc. Here are some of the things I took away from
that meeting.
We want to maintain the namespace as it is. A site might decide it
wants to deploy customer-user.py and have an entity named
customer-user, but the group plugin will still talk to the user.py
plugin internally. However, if all interaction is done via the
function calls, customer-user.py can replace user.py as the code that
handles, for example, user_add.
However, Rob Has ann approach that will allow an end site to extend an
existing plugin. His proof-of-concept was:
from ipalib.plugins.user import user, user_add
from ipapython import ipautil
from ipalib import api, errors
from ipalib import Str
from ipalib import _
class extend_user(user):
user.takes_params = user.takes_params + (
Str('foo',
cli_name='foo',
label=_('Foo'),
),
)
Which would add the attribute foo to the existing user object. This
will show up in the next metadata call, so the web UI can use it as well.
We discussed in depth whether this mechanism should succeed or fail if
the newly added name already exists in the Plugin. One option is to
succeed, but log the error. This means that if a user adds afield that
we late go bck and retrofit, the IPA site will work, but custom code
made by the end user will be ignored. The alternative is for IPA server
to fail to start, but allow all of the other components (KDC, LDAP) to
run. Then a user will just lose the ability to administer their site
until they address the conflict, but key services will still be available.
The web UI can implement a similar mechanism. We do not want end sites
modifying the .js files shipped with the IPA server RPM, other wise,
they could inject columns and fields there, but they would be
susceptible to breaking during upgrade. Instead, we will provide an
extension mechanism similar to the Library back end:
The Apache server will provide access to the file
/etc/ipa/html/extensions.json. By default, this file will contain the
simplest valid JSON possible:
{}
This file will be fetched via AJAX and evaluated during the
initialization of Entities. THe format of the file will indicate what
fields will be hidden in the UI, and what fields to add. As much as
possible, the format will match the Java script that is used to
poulated the entities.
Something along the lines of:
{entity:user,
search:{add:['foo'],
hide:['manager']},
details:{add:[ {identity: ['foo','bar']}],
hide:['manager']},
}
This would add one field to the search results, and two fields to the
details page, inside the identity section.
For the first pass, all added fields would be added as text fields.
On the second pass, the JSON listed above can be extended to allow
custom widgets in the field declarations.
On the third pass, we add in a second file:
/etc/ipa/html/custom_widgets.js. By default it will be blank.
This file will be added to the index.html of the webUI, and evaluated
after all of the other widgets, but before the entities. This will
allow the end sites to not only add in their own widgets, but to
possibly change the definition of some of the baseline widgets as well.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] minimum python?
So I looked in our freeipa spec file and I didn't see a minimum Python version specified. Do we have a minimum version of Python we require to run? Do we just make the assumption it's 2.6 since that's what's in RHEL? I also assume that means any Python feature added in 2.7 cannot be used, correct? -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 028 Code cleanup of HBAC, Sudo rules
On 10/27/2011 8:39 AM, Petr Vobornik wrote:
But still I think it would be better to be able to get container
(facet/dialog) for a widget. As you wrote, that.entity.get_facet() may
not always be what we want.
One possibility is to convert the facet dialog into subclasses of an
abstract container class. The container needs to provide functions such
as refresh() so the widget doesn't need to know whether it's a facet or
dialog.
Btw similar topic could be: How to get current entity's pkey?'.
Dependancy on facet.get_primary_key() or
IPA.nav.get_state(that.entity.name+'-pkey') seems wrong too.
Yes. Ideally we should have a path (REST-style URL) instead of the
current parameter-based URL. We should get the pkey from that path.
From dependency point of view, widgets would be still dependant on the
implementation of navigation (IMHO bad).
But it seems that using entity.get_primary key partially solves the
problem.
It could be argued that since this is a web app everything will have a
path, but for now getting primary key from entity is fine since
everything also has an associated entity.
Maybe it would be better if navigation would inject pkey to entity.
Entity wouldn't be that much dependant on navigation implementation.
We might need to distinguish 2 different usages of 'entity'. The first
one represents a collection of entries:
var users = IPA.get_entity('user');
users.add([ 'test' ], { givenName: 'Test', ... });
var result = users.find('t*');
The second one represents individual entry:
var user = result.result[0];
user.update({ sn: 'User' });
The entity collection should be 'stateless', it will be used in search
pages. The individual entity will be 'stateful', it contains the pkey
and the values of its attributes, and it will be used in the details page.
The entity.get_primary_key() is an interface to get the primary keys for
a particular entity from the current path. So when you open a URL for an
entry's details facet, it will execute the following command:
var pkeys = entity.get_primary_key();
var object = entity.get(pkeys);
Then the facet will use the object to populate the page.
The priority could be part of update info. As there is a field_info we
can create a command_info: { command, priority }.
Before adding commands to batch_command, array of command_info objects
would joined with 'mod' command with default priority and then sorted by
priority.
If the priority was set on each widget, priority management will be on
facet level, which may be fine. There can be some corner case like
dynamic change of priority.
I'd have to see how it's implemented.
One other solution is to split widgets into non-visual fields and purely
HTML components. Then in the facet we use separate lists for the fields
and HTML components. The fields will have a reference to the
corresponding HTML components. There can be more HTML components than
fields. But this will require a significant restructuring.
Maybe we can use hybrid solution: html widgets would be simple object
with some properties and create() method. They should not be called
widgets. They would not be part of sections fields. Rendering would be
done in widgets/sections create() method (as it is now).
I'm not very clear, we could be talking about the same thing. The
(non-HTML) fields could be defined like this:
fields: [
{
name: 'cn',
widget: 'identity.cn'
},
{
name: 'email',
widget: 'identity.email'
},
{
factory: IPA.password_field,
name: 'userpassword',
widgets: [ 'account.password1', 'account.password2' ]
}
]
The specs above will be used to create IPA.field objects (not widget) to
assist loading/saving attributes. Then we could also define the HTML
components (let's call it widget) separately:
widgets: [
{
factory: IPA.table_section,
name: 'identity',
label: 'Identity'
widgets: [
{
factory: IPA.text_widget,
name: 'cn'
},
{
factory: IPA.multivalued_widget,
name: 'email',
widget: IPA.text_widget
}
]
}
]
The specs above will be used to create IPA.widget objects to generate
the HTML content. If there is no widget specs specified, we could
generate it automatically from the field specs.
Pros:
- reusable layouts, headers...
- not polluting field names
Cons:
- not so declarative - need to override update method, create custom
section/widget factories - same as now
The above example should be quite declarative.
Question:
- what with widget nesting? rule_details_section is in fact a composite
widget. I would like to keep the concept, because it offers better code
reuse.
As shown above, widget (not field) nesting is possible.
A section is a composite widget with a specific
Re: [Freeipa-devel] minimum python?
John Dennis wrote: So I looked in our freeipa spec file and I didn't see a minimum Python version specified. Do we have a minimum version of Python we require to run? Do we just make the assumption it's 2.6 since that's what's in RHEL? I also assume that means any Python feature added in 2.7 cannot be used, correct? Correct. For the client we need to support 2.4 so keep that in mind too, but we can (and do) work around that on a per-client basis if we have to. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] minimum python?
On Thu, 27 Oct 2011, John Dennis wrote: So I looked in our freeipa spec file and I didn't see a minimum Python version specified. Do we have a minimum version of Python we require to run? Do we just make the assumption it's 2.6 since that's what's in RHEL? Yes. I'm not sure we tried hard to keep 2.4 working but 2.6 is definitely supported. I also assume that means any Python feature added in 2.7 cannot be used, correct? Yes. I had to rewrite code recently from views to sets due to the fact that dictionary views were added after 2.6... -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 028 Code cleanup of HBAC, Sudo rules
On 10/27/2011 05:51 PM, Endi Sukma Dewata wrote:
On 10/27/2011 8:39 AM, Petr Vobornik wrote:
But still I think it would be better to be able to get container
(facet/dialog) for a widget. As you wrote, that.entity.get_facet() may
not always be what we want.
One possibility is to convert the facet dialog into subclasses of an
abstract container class. The container needs to provide functions
such as refresh() so the widget doesn't need to know whether it's a
facet or dialog.
Btw similar topic could be: How to get current entity's pkey?'.
Dependancy on facet.get_primary_key() or
IPA.nav.get_state(that.entity.name+'-pkey') seems wrong too.
Yes. Ideally we should have a path (REST-style URL) instead of the
current parameter-based URL. We should get the pkey from that path.
From dependency point of view, widgets would be still dependant on the
implementation of navigation (IMHO bad).
But it seems that using entity.get_primary key partially solves the
problem.
It could be argued that since this is a web app everything will have a
path, but for now getting primary key from entity is fine since
everything also has an associated entity.
Maybe it would be better if navigation would inject pkey to entity.
Entity wouldn't be that much dependant on navigation implementation.
We might need to distinguish 2 different usages of 'entity'. The first
one represents a collection of entries:
Call that an instance. Entity is the term that is the analogue of Class
So we want to distinguish getting the primary key field for the entity,
as opposed to the primary key of the instance.
var users = IPA.get_entity('user');
users.add([ 'test' ], { givenName: 'Test', ... });
var result = users.find('t*');
The second one represents individual entry:
var user = result.result[0];
user.update({ sn: 'User' });
The entity collection should be 'stateless', it will be used in search
pages. The individual entity will be 'stateful', it contains the pkey
and the values of its attributes, and it will be used in the details
page.
The entity.get_primary_key() is an interface to get the primary keys
for a particular entity from the current path. So when you open a URL
for an entry's details facet, it will execute the following command:
var pkeys = entity.get_primary_key();
var object = entity.get(pkeys);
Then the facet will use the object to populate the page.
The priority could be part of update info. As there is a field_info we
can create a command_info: { command, priority }.
I'm a little unclear on the usage of priority.
Before adding commands to batch_command, array of command_info objects
would joined with 'mod' command with default priority and then sorted by
priority.
If the priority was set on each widget, priority management will be on
facet level, which may be fine. There can be some corner case like
dynamic change of priority.
I'd have to see how it's implemented.
One other solution is to split widgets into non-visual fields and
purely
HTML components. Then in the facet we use separate lists for the fields
and HTML components. The fields will have a reference to the
corresponding HTML components. There can be more HTML components than
fields. But this will require a significant restructuring.
Maybe we can use hybrid solution: html widgets would be simple object
with some properties and create() method. They should not be called
widgets. They would not be part of sections fields. Rendering would be
done in widgets/sections create() method (as it is now).
I think this is not quite right. Widget is just a generic term for an
element of the UI object model. It is intentionally generic. A Widget
can be just about anything. Some bind down to the individual fields, or
in somcses, even smaller, but widget could easily be the base class for
Facets, sections and the widget we have now.
I'm not very clear, we could be talking about the same thing. The
(non-HTML) fields could be defined like this:
fields: [
{
name: 'cn',
widget: 'identity.cn'
},
{
name: 'email',
widget: 'identity.email'
},
{
factory: IPA.password_field,
name: 'userpassword',
widgets: [ 'account.password1', 'account.password2' ]
}
]
The specs above will be used to create IPA.field objects (not widget)
to assist loading/saving attributes. Then we could also define the
HTML components (let's call it widget) separately:
widgets: [
{
factory: IPA.table_section,
name: 'identity',
label: 'Identity'
widgets: [
{
factory: IPA.text_widget,
name: 'cn'
},
{
factory: IPA.multivalued_widget,
name: 'email',
widget: IPA.text_widget
}
]
}
]
The specs above will be used to create
Re: [Freeipa-devel] Extending the IPA-API
On 10/27/2011 10:59 AM, Adam Young wrote:
The web UI can implement a similar mechanism. We do not want end sites
modifying the .js files shipped with the IPA server RPM, other wise,
they could inject columns and fields there, but they would be
susceptible to breaking during upgrade. Instead, we will provide an
extension mechanism similar to the Library back end:
The Apache server will provide access to the file
/etc/ipa/html/extensions.json. By default, this file will contain the
simplest valid JSON possible:
{}
This file will be fetched via AJAX and evaluated during the
initialization of Entities. THe format of the file will indicate what
fields will be hidden in the UI, and what fields to add. As much as
possible, the format will match the Java script that is used to poulated
the entities.
Something along the lines of:
{entity:user,
search:{add:['foo'],
hide:['manager']},
details:{add:[ {identity: ['foo','bar']}],
hide:['manager']},
}
I'd rather not use a descriptive language to perform object modification
because it's very limited. For example, the 'add' operation doesn't say
where the 'foo' should be added, whether it should be at the beginning
or the end, or before/after certain fields, etc. We could continue
expanding the language to support more complex logic, but why not just
use JS directly.
This would add one field to the search results, and two fields to the
details page, inside the identity section.
For the first pass, all added fields would be added as text fields.
On the second pass, the JSON listed above can be extended to allow
custom widgets in the field declarations.
On the third pass, we add in a second file:
/etc/ipa/html/custom_widgets.js. By default it will be blank.
I'd say we go directly with custom JS file and provide a good extensible
JS API. It will require the least effort from us.
Somewhere in the code we can define the default entities:
IPA.register('user', IPA.user.User);
IPA.register('group', IPA.group.Group);
Then in the custom JS file we can override the default entity:
IPA.register('user', com.example.user.User);
The custom entity can be defined as follows:
com.example.user.User = function(spec) {
// extend the default entity
var that = IPA.user.User(spec);
var init = function() {
// replace the original search facet
that.add_facet(com.example.user.SearchFacet({
name: 'search'
});
};
init();
return that;
};
com.example.user.SearchFacet = function(spec) {
// extend the default search facet
var that = IPA.user.SearchFacet(spec);
var init = function() {
// find phone's position
var i = that.get_field_index('phone');
// add fax after phone
that.add_field(i+1, 'fax');
};
init();
return that;
};
Then later we can design a descriptive language that will cover most
common use cases.
This file will be added to the index.html of the webUI, and evaluated
after all of the other widgets, but before the entities. This will allow
the end sites to not only add in their own widgets, but to possibly
change the definition of some of the baseline widgets as well.
--
Endi S. Dewata
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
