[Freeipa-users] Add attributes to default user schema

[Stephen Ingram]

On Fri, Jun 22, 2012 at 1:37 PM, Rob Crittenden <rcritten at redhat.com> wrote:
> Dmitri Pal wrote:
>>
>> On 06/22/2012 12:28 PM, Stephen Ingram wrote:
>>>
>>> On Fri, Jun 22, 2012 at 6:25 AM, Dmitri Pal<dpal at redhat.com>  wrote:
>>>>
>>>> On 06/22/2012 01:57 AM, Stephen Ingram wrote:
>>>>>
>>>>> On Thu, Jun 21, 2012 at 3:22 PM, Dmitri Pal<dpal at redhat.com>  wrote:
>>>>>>
>>>>>> On 06/21/2012 05:44 PM, Stephen Ingram wrote:
>>>>>>>
>>>>>>> On Thu, Jun 21, 2012 at 2:06 PM, James James<jreg2k at gmail.com>
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> Hi everybody,
>>>>>>>>
>>>>>>>> Is it possible to have a procedure to add new attributes like
>>>>>>>> mailAlternateAddress in the default user schema ?
>>>>>>>
>>>>>>> That particular attribute is included in the schema
>>>>>>> (objectclass=mailRecipient) so it is easy to add using the ipa
>>>>>>> user-mod --addattr command. I then followed Adam Young's instructions
>>>>>>> to change the interface such that we could view/edit the new
>>>>>>> attribute
>>>>>>> in the UI:
>>>>>>>
>>>>>>> 1. Edit the /usr/lib/python2.7/site-packages/ipalib/plugins/user.py
>>>>>>> to
>>>>>>> include the new field
>>>>>>> 2. Add an entry to /usr/share/ipa/ui/user.js for the new value
>>>>>>> 3. Don't forget to restart httpd and refresh your browser cache to
>>>>>>> pick up the new fields
>>>>>>>
>>>>>>> We needed that instead of using the multi-valued mail attribute
>>>>>>> because there are circumstances where we need to differentiate
>>>>>>> between
>>>>>>> the "master" email address and aliases. It's easy to add though and
>>>>>>> works great. I certainly wouldn't want to be in the position of
>>>>>>> adding
>>>>>>> lots of attributes not already included in IPA, but a one or two-off
>>>>>>> seems pretty reasonable to manage.
>>>>>>>
>>>>>>> I don't know if it's still in the I'm sure *very* future plans for
>>>>>>> IPA, but I remember seeing some application (MTA, mail store) support
>>>>>>> mentioned at one time. These sorts of attributes might be nice to
>>>>>>> have
>>>>>>> if and when that happens.
>>>>>>>
>>>>>>> Steve
>>>>>>
>>>>>> Is there any chance you can submit what you have done in the form of a
>>>>>> ticket with attached patches?
>>>>>
>>>>> As I have not upgraded to 2.2 yet, I had to patch against 2.1.4. Ticket
>>>>> is 2863.
>>>>>
>>>>> Steve
>>>>
>>>> Thank you for the ticket.
>>>> I think it would be OK to attach existing patch anyways for now.
>>>> What are your plans regarding upgrading to 2.2 and rebasing the patches?
>>>
>>> I see that RHEL 6.3 was released yesterday so we will start testing
>>> 2.2 soon. Once we upgrade, I'll rebase patches to 2.2 and attach to
>>> existing ticket. Is this something that might be included at some
>>> point?
>>>
>>> Steve
>>
>> In general yes, but devil is in details.
>>
>
> It should be pretty straightforward to rebase these.
>
> I wonder about the objectclass. It would also be possible to add it
> on-the-fly by adding a bit of code to the pre_callback() of user_mod and
> user_add.
>
> The basic idea would be:
>
> user_add::pre_callback()
>
> if 'mailalternateaddress' in entry_attrs:
>    entry_attrs['objectclass'] =
> list(set(entry_attrs['objectclass'].append('mailRecipient')))
>
> I do the list/set bit in case anyone adds mailRecipient to the default list
> :-)
>
> Something similar in user_mod, there is similar code to do this for
> 'ipasshpubkey'. Might be worthwhile to make this into its own function.

This sounds really neat! It sounds like you are adding the
mailRecipient objectclass if you find mailalternateaddress? Is this so
if you add this attribute with the CLI, that objectclass will also be
added? I'm curious because I had to actually add the mailRecipient
objectclass just to be able to add mailAlternateAddress as I don't
believe it is in any of the default objectclasses. I was OK with that
because not all of our entries require this so I actually base my
directory queries on whether or not mailRecipient exists.

Steve