[Freeipa-devel] Extending the IPA-API

[Adam Young]

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.