Re: [Freeipa-devel] [PATCH] 028 Code cleanup of HBAC, Sudo rules
On 10/27/2011 6:39 PM, Adam Young wrote: 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 Not sure I understand correctly. You mean entity is a class which is a collection, similar to a table in database? And instance is an object or individual entry or row in a table? So we want to distinguish getting the primary key field for the entity, as opposed to the primary key of the instance. From the URL we want to get the primary key for a particular instance/object to show in the detail page. The IPA.client will represent a connection to the IPA server. In a browser IPA.client can only connect to the server it's loaded from: var client = IPA.client(); but in a JS engine like Rhino the IPA.client can connect to any IPA server: var client = IPA.client('ipa.example.com'); This will work now, but you will not be able to see the results of the command. Integrations like this are how the Like buttons from Facebook work. Cross site posting is tricky, but permitted, and might be useful in some cases. Possibly we should call it connection. The second code is not supposed to be used inside a browser. This is suppose you're writing a JS script running in Rhino, you need to specify the IPA server you're connecting to. I haven't tried this, but I suppose in Rhino we will be able to set the Referer to match the server name. I'd rather call it IPA.client because it will do other things too, not just connection. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
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
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] 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] 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] [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 specifi
[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 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
[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
Re: [Freeipa-devel] [PATCH] 301 Added password field in user adder dialog.
On 10/27/2011 10:04 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] 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
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] 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 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] 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] 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] 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] 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] 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] 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] ipalib vs. ipapython?
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. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
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
[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 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 b/tests/test_ipalib/te
[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 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; i___ 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
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] 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] 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] 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] 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] 299 Merged widget's metadata and param_info.
On 10/26/2011 07:59 PM, Endi Sukma Dewata wrote: The metadata and param_info attributes in widget have been merged because they are redundant. Ticket #1436 ACK -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
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