On 08/17/2010 08:12 PM, Adam Young wrote:
The structure of our details code is basciallt
[categorid, categoryDisplay, atrrtibutes]
and attributes are
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
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.
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 <collection>-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
That's one possible way. I was thinking of something a little bit different, but
similar from the user perspective.
We could have the <insert-object-name-here>-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.
Freeipa-devel mailing list