Re: [Freeipa-devel] [PATCH] 354 removing bogus code
Rob Crittenden wrote: Somehow the same block of code got added twice to ipa-rmkeytab causing, not surprisingly, a double-free. This resolves it. rob ack Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 034 Enable WebUI CRUDS using wehjit 0.2.0
This patch enables webUI Create-Retrieve-Updated-Delete-Search
operations for all api.Object plugins that:
1. implement all the required CRUDS methods
2. have a primary_key
Last night I realized that the upgrade to wehjit 0.2.0 broke the
installer, so I hurried this patch a bit, left out some niceties that
still need a bit more testing and tweaking.
From 073cea91cca082ec0f8d4d0644ff9db1961bfba9 Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose jder...@redhat.com
Date: Tue, 26 Jan 2010 06:39:00 -0700
Subject: [PATCH] Enabled CRUDS in webUI using wehjit 0.2.0
---
ipalib/plugable.py |2 +
ipalib/plugins/baseldap.py |7 +-
ipalib/plugins/user.py |3 +
ipaserver/rpcserver.py |3 +
ipawebui/engine.py | 124 +++---
ipawebui/widgets.py| 301 ++--
6 files changed, 241 insertions(+), 199 deletions(-)
diff --git a/ipalib/plugable.py b/ipalib/plugable.py
index 3ee2bd5..ecccb79 100644
--- a/ipalib/plugable.py
+++ b/ipalib/plugable.py
@@ -531,6 +531,8 @@ class API(DictProxy):
value = getattr(options, key, None)
if value is not None:
overrides[key] = value
+if hasattr(options, 'prod'):
+overrides['webui_prod'] = options.prod
if context is not None:
overrides['context'] = context
self.bootstrap(**overrides)
diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py
index 17db048..eeea7a6 100644
--- a/ipalib/plugins/baseldap.py
+++ b/ipalib/plugins/baseldap.py
@@ -133,6 +133,7 @@ class LDAPCreate(crud.Create):
Create a new entry in LDAP.
+
takes_options = (
Flag('raw',
cli_name='raw',
@@ -142,6 +143,7 @@ class LDAPCreate(crud.Create):
Flag('all',
cli_name='all',
doc='retrieve all attributes',
+exclude='webui',
),
Str('addattr*', validate_add_attribute,
cli_name='addattr',
@@ -291,14 +293,17 @@ class LDAPUpdate(LDAPQuery, crud.Update):
Update an LDAP entry.
+
takes_options = (
Flag('raw',
cli_name='raw',
doc='print entries as they are stored in LDAP',
+exclude='webui',
),
Flag('all',
cli_name='all',
doc='retrieve all attributes',
+exclude='webui',
),
Str('addattr*', validate_add_attribute,
cli_name='addattr',
@@ -456,6 +461,7 @@ class LDAPModMember(LDAPQuery):
Flag('raw',
cli_name='raw',
doc='print entries as they are stored in LDAP',
+exclude='webui',
),
)
@@ -751,4 +757,3 @@ class LDAPSearch(crud.Search):
def post_callback(self, ldap, entries, truncated, *args, **options):
pass
-
diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py
index 97641a4..1686d67 100644
--- a/ipalib/plugins/user.py
+++ b/ipalib/plugins/user.py
@@ -113,6 +113,9 @@ class user(LDAPObject):
cli_name='password',
label='Password',
doc='Set the user password',
+# FIXME: This is temporary till bug is fixed causing updates to
+# bomb out via the webUI.
+exclude='webui',
),
Int('uidnumber?',
cli_name='uid',
diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py
index a42c3d0..e84cb07 100644
--- a/ipaserver/rpcserver.py
+++ b/ipaserver/rpcserver.py
@@ -273,4 +273,7 @@ class jsonserver(WSGIExecutioner):
raise JSONError(
error='params[1] (aka options) must be a dict'
)
+options = dict((str(k), v) for (k, v) in options.iteritems())
+print 'args = %r' % (args,)
+print 'options = %r' % (options,)
return (method, args, options, _id)
diff --git a/ipawebui/engine.py b/ipawebui/engine.py
index a90a450..01b271a 100644
--- a/ipawebui/engine.py
+++ b/ipawebui/engine.py
@@ -65,7 +65,17 @@ class ParamMapper(object):
)
+def filter_params(namespace):
+for param in namespace():
+if param.exclude and 'webui' in param.exclude:
+continue
+yield param
+
+
class Engine(object):
+
+cruds = frozenset(['add', 'show', 'mod', 'del', 'find'])
+
def __init__(self, api, app):
self.api = api
self.app = app
@@ -86,11 +96,21 @@ class Engine(object):
)
def build(self):
-for cmd in self.api.Object.user.methods():
-self.pages[cmd.name] = self.build_page(cmd)
-for page in self.pages.itervalues():
-page.menu.label = 'Users'
-self.add_object_menuitems(page.menu, 'user')
+for obj in self.api.Object():
+if self.cruds.issubset(obj.methods) and obj.primary_key is not None:
+self.pages[obj.name] = self.build_cruds_page(obj)
+
+# Add landing page:
+
Re: [Freeipa-devel] [PATCH] jderose 034 Enable WebUI CRUDS using wehjit 0.2.0
Pavel Zu*na wrote: Jason Gerard DeRose wrote: This patch enables webUI Create-Retrieve-Updated-Delete-Search operations for all api.Object plugins that: 1. implement all the required CRUDS methods 2. have a primary_key Last night I realized that the upgrade to wehjit 0.2.0 broke the installer, so I hurried this patch a bit, left out some niceties that still need a bit more testing and tweaking. Just what I needed - had to switch all my test VMs to F12, because of dependencies and was about to bug someone about the broken installer. :) Looks fine and fixes the installer, so ACK from me. Pavel Works great for me too. Pushed to master. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 354 removing bogus code
Pavel Zůna wrote: Rob Crittenden wrote: Somehow the same block of code got added twice to ipa-rmkeytab causing, not surprisingly, a double-free. This resolves it. rob ack Pavel pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] not ascii, not utf-8, what's a parser supposed to do?
I've run into a small problem with xgettext. By default xgettext expects all strings in an input file to be encoded in ascii. It will also allow you to override that by specifying the strings in the input file are utf-8. In ipappython/ipautil.py line 296 is the following string: SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|)|[\000\n\r\200-\377]+|[ ]+$)' In it's default ascii mode xgettext throws an error claiming the string is not ascii. In fact xgettext is correct, the string is not ascii. (You may be wondering why xgettext even cares since it's not marked as translatable, but xgettext fully parses the input before deciding what is marked as translatable, bottom line: all strings get parsed and decoded). If I override the default ascii input by telling xgettext the input strings are encoded in utf-8 xgettext stops complaining, the string is properly skipped. But ... the string isn't really utf-8 either and I'm not sure how comfortable I feel about telling xgettext every string in IPA is encoded in utf-8 (when it isn't) just to get around this failure, especially since the offending string isn't even utf-8. (However, maybe we should allow utf-8 as an input format since ascii is a subset of utf-8, we might want to use utf-8 in the future and we can just hold our noses with respect to the above regular expression). Do we have a stake in the ground as to what our input strings are encoded in? Can you think of another way to express the offending string such that it doesn't trigger the non-ascii error? The only thing I could think of and get to work was this: SAFE_STRING_PATTERN='%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c' % \ (40,94,40,0,124,10,124,13,124,32,124,58,124,60,41,124,91,0,10,13,128,45,255,93,43,124,91,32,93,43,36,41) Which is pretty unreadable, but with sufficient comments could be acceptable. -- 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] not ascii, not utf-8, what's a parser supposed to do?
On Tue, 2010-01-26 at 17:28 -0500, John Dennis wrote: I've run into a small problem with xgettext. By default xgettext expects all strings in an input file to be encoded in ascii. It will also allow you to override that by specifying the strings in the input file are utf-8. In ipappython/ipautil.py line 296 is the following string: SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|)|[\000\n\r\200-\377]+|[ ]+$)' ipapython still has a lot of legacy code, so first thing we should do is check if we even use SAFE_STRING_PATTERN. Rob, do you know off hand? In it's default ascii mode xgettext throws an error claiming the string is not ascii. In fact xgettext is correct, the string is not ascii. (You may be wondering why xgettext even cares since it's not marked as translatable, but xgettext fully parses the input before deciding what is marked as translatable, bottom line: all strings get parsed and decoded). If I override the default ascii input by telling xgettext the input strings are encoded in utf-8 xgettext stops complaining, the string is properly skipped. But ... the string isn't really utf-8 either and I'm not sure how comfortable I feel about telling xgettext every string in IPA is encoded in utf-8 (when it isn't) just to get around this failure, especially since the offending string isn't even utf-8. (However, maybe we should allow utf-8 as an input format since ascii is a subset of utf-8, we might want to use utf-8 in the future and we can just hold our noses with respect to the above regular expression). Do we have a stake in the ground as to what our input strings are encoded in? Can you think of another way to express the offending string such that it doesn't trigger the non-ascii error? The only thing I could think of and get to work was this: SAFE_STRING_PATTERN='%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c' % \ (40,94,40,0,124,10,124,13,124,32,124,58,124,60,41,124,91,0,10,13,128,45,255,93,43,124,91,32,93,43,36,41) Which is pretty unreadable, but with sufficient comments could be acceptable. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] not ascii, not utf-8, what's a parser supposed to do?
John Dennis wrote: I've run into a small problem with xgettext. By default xgettext expects all strings in an input file to be encoded in ascii. It will also allow you to override that by specifying the strings in the input file are utf-8. Do you ever expect to run this stuff on IBM mainframes (i.e., systems using EBCDIC or some other non-ASCII-related character set) ? Can you think of another way to express the offending string such that it doesn't trigger the non-ascii error? The only thing I could think of and get to work was this: SAFE_STRING_PATTERN='%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c' % \ (40,94,40,0,124,10,124,13,124,32,124,58,124,60,41,124,91,0,10,13,128,45,255,93,43,124,91,32,93,43,36,41) Which is pretty unreadable, but with sufficient comments could be acceptable. I had to use similar hacks when porting OpenSSL to z/OS. It kinda sucks, but it has the virtue of being completely independent of the machine's language settings. And frankly, it doesn't take too much explanation in the comments to be understandable. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Why do we have so much duplicated code?
I constantly find identical code spread across multiple files. Is there a reason for this code duplication? (Perhaps trying to keep import name spaces isolated?) It seems to me code duplication is bad software practice for obvious reasons. If there isn't a compelling design justification for the duplication can we start moving some of this stuff to common libraries? -- 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
