[Freeipa-users] Add attributes to default user schema

[Rob Crittenden]

Stephen Ingram wrote:
> 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

Right, this makes it more automatic so you don't also have to use 
--addattr objectclass=mailRecipient or some other mechanism to add the 
objectclass too.

rob