[Freeipa-devel] Extending Details, user and otherwise

[Pavel Zuna]

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 <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
> 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 <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.

Pavel