[Freeipa-devel] [PATCH] admiyo-freeipa-0014-remove-user-html
This file has not been used for a long time. I wanted to remove it in its own patch. >From b283bf9a42e5e9843e0b965f5110cfc9dd25b4d7 Mon Sep 17 00:00:00 2001 From: Adam Young Date: Mon, 23 Aug 2010 11:52:23 -0400 Subject: [PATCH] Removed unused file. --- install/static/user.html | 112 -- 1 files changed, 0 insertions(+), 112 deletions(-) delete mode 100644 install/static/user.html diff --git a/install/static/user.html b/install/static/user.html deleted file mode 100644 index c7a77b8..000 --- a/install/static/user.html +++ /dev/null @@ -1,112 +0,0 @@ - -http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd";> - -http://www.w3c.org/1999/xhtml"; lang="en" xml:lang="en" -xmlns:py="http://genshi.edgewall.org/";> - - - -jQuery test page for IPA - - - - - - - - - - - - - - - - - - - -Logged in as - - - - -Managing user: - - - - - -View: - - -Personal Details - - - -Memberships - - - - -− Identity Details - -Title: -First Name: -Last Name: -Full Name: -Display Name: -Initials: - - - -− Account Details - -Account Status: -Login: -Password: -UID: -GID: -Home Directory: - - - -− Contact Details - -E-mail Address: -Numbers: - - - -− Mailing Address - -Address: -City: -State: -ZIP: - - - -− Employee Information - -Org. Unit: -Manager: - - - -− Misc. Information - -Car License: - - - - -Back to Top - - - - - - - -- 1.7.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] admiyo-freeipa-0013 Revert of the host details patch
On 08/20/2010 11:19 AM, Adam Young wrote: That patch got pushed by accident. Reverting. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add webUI application to lite-server.
Rob Crittenden wrote: Pavel Zůna wrote: The web UI should now be available through the lite-server. For security purposes only files under install/static ending with extensions listed in lite-server:WebUIApp.EXTENSION_TO_MIME_MAP dict are served. Pavel nack. This does seem to somewhat serve the UI through the lite server but it isn't quite functional. It should probably have a redirect from / to /ipa/ui/index.html, and perhaps look for index.xhtml if given a directory URI. In any case, the best I was able to get was the title bar to display along with the word Edit. For this patch to work it requires "Fix script tags in index.xhtml. End tag is required." which is acked but not pushed. With that patch I was able to see the UI. I still think it should be a bit friendlier about redirecting to the actual UI but that can come later. ACK rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix script tags in index.xhtml. End tag is required.
On 2010-08-20 02:26, Adam Young wrote: On 08/19/2010 06:51 PM, Pavel Zůna wrote: On 2010-08-20 00:48, Pavel Zůna wrote: The paste server had some issues with it and end tags are required by the standard anyway. Pavel I forgot to mention that this applies after Adam's 0009 patch (updated Hash Params). Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Is this only a problem on the javascript tags, or are we going to see a problem on all of the xhtml that doesn't use closing tags? Either way, it should be filed as an upstream bug. I think it's just the script tags. From wiki (http://en.wikipedia.org/wiki/XHTML): The format , rather than the more concise , is required for HTML compatibility when served as MIME type text/html. I know we were using application/xhtml+json at some point in the old UI. text/html seems to have better support though. Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add webUI application to lite-server.
Pavel Zůna wrote: The web UI should now be available through the lite-server. For security purposes only files under install/static ending with extensions listed in lite-server:WebUIApp.EXTENSION_TO_MIME_MAP dict are served. Pavel nack. This does seem to somewhat serve the UI through the lite server but it isn't quite functional. It should probably have a redirect from / to /ipa/ui/index.html, and perhaps look for index.xhtml if given a directory URI. In any case, the best I was able to get was the title bar to display along with the word Edit. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] BA-BBQ
On 2010-08-23 16:41, Adam Young wrote:
On 08/23/2010 07:51 AM, Pavel Zuna wrote:
On 08/23/2010 04:12 AM, Adam Young wrote:
Pavel,
Thoughts of jquery.ba-bbq have been marinating in the back of my brain.
I know that the Back button doesn't work so well with hjashparams, and
that BBQ purports to fix this, but I had some sort of mental shift I had
to make. I think I have it now.
BBQ, and in fact the whole AJAX approach works off of client side code,
which means the whole hash params approach. What I didn't get was that
the best approach to dealing with this was to drive the site off of the
event that happens when the url hash changes. We need to do this.
Bascially, navigation.js registers:
$(window).bind( 'hashchange', function(e) {
...
}
This function gets called each time the URL hash changes, which happens
on either a tab click or on a back button (lets start with those two,
there will be more)
So bascially, this function is our dispatach. Instead of having to
register the onclick functions for each of the tabs, we know that they
will all end up in this function, and then we let it parse the params
for us.
BBQ has the concept of a stack, where we can push and pop state. Thyis
might be useful for pushing a query, going to the details page, and then
popping the query afterwards. I'm still mulling this over.
Note, we will want to replace the custom hash param working we are doing
with JQuery.deparam and JQuery.param calls, as they are much more
mature, and it is less code we have to debug.
Sure, from what I've read in jQuery docs, it looks more powerful than
what we currently have.
The thing I have to figure out now is what this will do to navigation on
the details, add and groups pages.
I don't think it will be a problem. Functional links (such as Reset,
Update, Add, Remove) are only used to run javascript functions - the
URL, query string or hash doesn't change. Most of these action are
also "one way" only. We don't want the user to be able to go Back
after he updated an entry. (Going back in this case should probably
bring him back to the search page).
Pavel
I notice he uses JQuery.ui Tabs for his demo. I wonder if we want to
move to that as well?
http://benalman.com/code/projects/jquery-bbq/examples/fragment-jquery-ui-tabs/
You mean this example, right? It looks good and if it can simplify our
code, why not. I'll take a look at the API a maybe play around with it a
little.
Pavel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Fwd: [Freeipa-users] [PATCH] 510 enable compat plugin by default
Adam Young wrote: On 08/11/2010 04:07 PM, Rob Crittenden wrote: originall sent to wrong list ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] admiyo-freeipa-0013 Revert of the host details patch
Adam Young wrote: That patch got pushed by accident. Reverting. ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] BA-BBQ
On 08/23/2010 07:51 AM, Pavel Zuna wrote:
On 08/23/2010 04:12 AM, Adam Young wrote:
Pavel,
Thoughts of jquery.ba-bbq have been marinating in the back of my brain.
I know that the Back button doesn't work so well with hjashparams, and
that BBQ purports to fix this, but I had some sort of mental shift I had
to make. I think I have it now.
BBQ, and in fact the whole AJAX approach works off of client side code,
which means the whole hash params approach. What I didn't get was that
the best approach to dealing with this was to drive the site off of the
event that happens when the url hash changes. We need to do this.
Bascially, navigation.js registers:
$(window).bind( 'hashchange', function(e) {
...
}
This function gets called each time the URL hash changes, which happens
on either a tab click or on a back button (lets start with those two,
there will be more)
So bascially, this function is our dispatach. Instead of having to
register the onclick functions for each of the tabs, we know that they
will all end up in this function, and then we let it parse the params
for us.
BBQ has the concept of a stack, where we can push and pop state. Thyis
might be useful for pushing a query, going to the details page, and then
popping the query afterwards. I'm still mulling this over.
Note, we will want to replace the custom hash param working we are doing
with JQuery.deparam and JQuery.param calls, as they are much more
mature, and it is less code we have to debug.
Sure, from what I've read in jQuery docs, it looks more powerful than
what we currently have.
The thing I have to figure out now is what this will do to navigation on
the details, add and groups pages.
I don't think it will be a problem. Functional links (such as Reset,
Update, Add, Remove) are only used to run javascript functions - the
URL, query string or hash doesn't change. Most of these action are
also "one way" only. We don't want the user to be able to go Back
after he updated an entry. (Going back in this case should probably
bring him back to the search page).
Pavel
I notice he uses JQuery.ui Tabs for his demo. I wonder if we want to
move to that as well?
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 515 F-14 compatibility patch
Adam Young wrote: On 08/20/2010 04:20 PM, Rob Crittenden wrote: F-14 introduced a number of changes including an updated krb5 server package and python 2.7. In krb5 the binaries moved from /usr/kerberos/* to /usr/* so some paths need to be adjusted. What I did was include a PATH in the env that covers both of these locations. Python 2.7 made some changes to xmlrpclib and httplib as well that aren't quite backwards compatible. I added some specific version checks so we can do the right thing internally. This is ticket 155 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I think that in the explicit path construction you do vic of line 115, you want the kerberos subpath libraries to come before /usr/bin, otherwise it will find the non-kerberized versions of the function. Ok, it wouldn't affect the commands we're currently using but flipping the order will certainly help. I need to add /bin to it as well. I realize that testing on the Major/Minor is functional, but wouldn't it make more sense to test for the existanec of the newer call, use that if it was avaiable, as opposed to gating on version number? Seems like it would be less prone to breakage. I did that originally and it was extremely unreadable. Since xmlrpclib ships with core python testing the version seems adequate. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Extending Details, user and otherwise
On 08/23/2010 08:28 AM, Pavel Zuna wrote: On 08/17/2010 08:12 PM, Adam Young wrote: The structure of our details code is basciallt [categorid, categoryDisplay, atrrtibutes] and attributes are [attributeId, attributeDisplay, I've inlined the user details at the bottom as an example. In order to make these configuratble by the end user, here is a strawman proposal: Create a dir under /var/lib/ipa/details with code that will, at run time, get validated and then appended to the web code. This code, unlike the resources approach, will not be autogenerated. The code for the user details gets pre-populated there from a static copy somewhere under /usr/share/ipa. The end user can then customize it to add or remove fields. If they so desire, they can add in custom javascript code that will provide more advanced UI. An example might be a n interactive map for showing seat and parking assignments. IPA server install and uninstall will be aware of these files, and treat them gently. Doing an install will not over write the files if they are present, but will instead rename and back them up. Same with uninstall, unless an additional option is given ( for example --ultraclean) the is repsonbile for removing all vestiges of IPA from a system. The details pages will be named -details.js: user-details.js, group-details.js and so forth. As I said, this is a strawman. Please poke holes in it, and make better suggestions. That's one possible way. I was thinking of something a little bit different, but similar from the user perspective. We could have the -details.js files under (for example) /etc/ipa/webui/ and /usr/share/ipa/static would have symlinks to them. It's basically the same thing Adam proposed, but in this case, we don't have to monitor, generate or append anything. We only need to make sure not to overwrite these files after installation. Take it as just another proposal, because I'm not sure if it's 100% compatible with the Linux file system philosophy. There might also be some security risks using symlinks to /etc/*, although I'm not aware of any. Pavel I think that, so long as you tell the Apache server that follow symlinks is OK, this should work. I think it is secure as well. In order to corrupt the apache server, you would need to be able to change what is at the far end of the symlink, which means you have root privs already. I'm OK with this approach. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Fwd: Python 3.2a1 in rawhide
From the the Fedora devel list. Hopefully this will just be a minor packaging change. I filed ticket #157 to track this. rob --- Begin Message --- I just built Python 3.2a1 into rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=191382 so the meaning of "python3" in rawhide just jumped from Python 3.1 to Python 3.2 A new opcode (SETUP_WITH [1]) was added, to speed up the "with" statement, and this changes the bytecode format for python 3. python3's provides changes from: python(abi) = 3.1 libpython3.1.so.1.0() to python(abi) = 3.2 libpython3.2.so.1.0() So once that package hits the buildroot for rawhide, everything that builds a python3 package or subpackage will need to be rebuilt, to use the new bytecode format. Thankfully this will be a much smaller-scale rebuild than the recent 2.7 rebuilds. To liven things up a bit, the layout of how Python stores cached bytecode has changed somewhat. The full details can be seen at: http://www.python.org/dev/peps/pep-3147/ but to summarize, where before you had: foo/__init__.py foo/bar.py foo/baz.py with cached bytecode: foo/__init__.pyc foo/__init__.pyo foo/bar.pyc foo/baz.pyo foo/bar.pyc foo/baz.pyo with Python 3.2 onwards you now have a __pycache__ directory: foo/__init__.py foo/bar.py foo/baz.py foo/__pycache__/ foo/__pycache__/__init__.cpython-32.pyc foo/__pycache__/__init__.cpython-32.pyo foo/__pycache__/foo.cpython-32.pyc foo/__pycache__/foo.cpython-32.pyo foo/__pycache__/bar.cpython-32.pyc foo/__pycache__/bar.cpython-32.pyo and the files are explicitly for "CPython 3.2" (the "32" above refers to the python version, not the architecture; this threw me initially). The idea is to permit sharing of modules between multiple parallel-installable versions of Python. So you'll need to update the %files for python3 subpackages, listing something like: foo/__pycache__ to capture the directory and the bytecode files within. Hope this makes sense Dave [1] http://svn.python.org/view?view=rev&revision=73597 -- devel mailing list de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel --- End Message --- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Extending Details, user and otherwise
On 08/17/2010 08:12 PM, Adam Young wrote: The structure of our details code is basciallt [categorid, categoryDisplay, atrrtibutes] and attributes are [attributeId, attributeDisplay, I've inlined the user details at the bottom as an example. In order to make these configuratble by the end user, here is a strawman proposal: Create a dir under /var/lib/ipa/details with code that will, at run time, get validated and then appended to the web code. This code, unlike the resources approach, will not be autogenerated. The code for the user details gets pre-populated there from a static copy somewhere under /usr/share/ipa. The end user can then customize it to add or remove fields. If they so desire, they can add in custom javascript code that will provide more advanced UI. An example might be a n interactive map for showing seat and parking assignments. IPA server install and uninstall will be aware of these files, and treat them gently. Doing an install will not over write the files if they are present, but will instead rename and back them up. Same with uninstall, unless an additional option is given ( for example --ultraclean) the is repsonbile for removing all vestiges of IPA from a system. The details pages will be named -details.js: user-details.js, group-details.js and so forth. As I said, this is a strawman. Please poke holes in it, and make better suggestions. That's one possible way. I was thinking of something a little bit different, but similar from the user perspective. We could have the -details.js files under (for example) /etc/ipa/webui/ and /usr/share/ipa/static would have symlinks to them. It's basically the same thing Adam proposed, but in this case, we don't have to monitor, generate or append anything. We only need to make sure not to overwrite these files after installation. Take it as just another proposal, because I'm not sure if it's 100% compatible with the Linux file system philosophy. There might also be some security risks using symlinks to /etc/*, although I'm not aware of any. Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] BA-BBQ
On 08/23/2010 04:12 AM, Adam Young wrote:
Pavel,
Thoughts of jquery.ba-bbq have been marinating in the back of my brain.
I know that the Back button doesn't work so well with hjashparams, and
that BBQ purports to fix this, but I had some sort of mental shift I had
to make. I think I have it now.
BBQ, and in fact the whole AJAX approach works off of client side code,
which means the whole hash params approach. What I didn't get was that
the best approach to dealing with this was to drive the site off of the
event that happens when the url hash changes. We need to do this.
Bascially, navigation.js registers:
$(window).bind( 'hashchange', function(e) {
...
}
This function gets called each time the URL hash changes, which happens
on either a tab click or on a back button (lets start with those two,
there will be more)
So bascially, this function is our dispatach. Instead of having to
register the onclick functions for each of the tabs, we know that they
will all end up in this function, and then we let it parse the params
for us.
BBQ has the concept of a stack, where we can push and pop state. Thyis
might be useful for pushing a query, going to the details page, and then
popping the query afterwards. I'm still mulling this over.
Note, we will want to replace the custom hash param working we are doing
with JQuery.deparam and JQuery.param calls, as they are much more
mature, and it is less code we have to debug.
Sure, from what I've read in jQuery docs, it looks more powerful than what we
currently have.
The thing I have to figure out now is what this will do to navigation on
the details, add and groups pages.
I don't think it will be a problem. Functional links (such as Reset, Update,
Add, Remove) are only used to run javascript functions - the URL, query string
or hash doesn't change. Most of these action are also "one way" only. We don't
want the user to be able to go Back after he updated an entry. (Going back in
this case should probably bring him back to the search page).
Pavel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
