[Freeipa-devel] Status/Question about User life cycle

[Jan Cholasta]

On 19.5.2014 16:34, thierry bordaz wrote:
> On 05/19/2014 04:22 PM, Jan Cholasta wrote:
>> On 19.5.2014 16:03, thierry bordaz wrote:
>>> On 05/19/2014 03:54 PM, Jan Cholasta wrote:
>>>> On 19.5.2014 15:19, Petr Viktorin wrote:
>>>>> Hello list,
>>>>> Here's a conversation that started internally. I'm making it public.
>>>>>
>>>>> On 05/19/2014 01:00 PM, Martin Kosek wrote:
>>>>>> On 05/19/2014 12:46 PM, Petr Viktorin wrote:
>>>>>>> On 05/19/2014 08:25 AM, Martin Kosek wrote:
>>>>>>>> On 05/19/2014 08:24 AM, Martin Kosek wrote:
>>>>>>>>> On 05/16/2014 04:48 PM, thierry bordaz wrote:
>>>>>>>>>> Hello Martin,
>>>>>>>>>>
>>>>>>>>>>      I am getting familiar with the freeipa CLI code and started
>>>>>>>>>>      implemented '--to-stage' and '--from-stage'. This really an
>>>>>>>>>>      impressive set of code :-)
>>>>>>>>>
>>>>>>>>> Great! :-)
>>>>>>>>>
>>>>>>>>>>      I completed 'to-stage' and testing '--from-stage'.
>>>>>>>>>>
>>>>>>>>>>      I have a question regarding the '--from-stage' syntax. 'uid'
>>>>>>>>>> is a
>>>>>>>>>>      mandatory argument to 'user-add' subcommand. In the
>>>>>>>>>> design the
>>>>>>>>>>      '--from-stage' option is described with:
>>>>>>>>>>
>>>>>>>>>>          ipa user-add --from-stage=tuser
>>>>>
>>>>> Note, the design is here:
>>>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management
>>>>>
>>>>>>>>>>      But as 'uid' is mandatory the command should rather be
>>>>>>>>>>
>>>>>>>>>>          ipa user-add tuser --from-stage=tuser
>>>>>>>>>>
>>>>>>>>>>      In that case the option value for '--from-stage' is not
>>>>>>>>>> required and
>>>>>>>>>>      the command should be
>>>>>>>>>>
>>>>>>>>>>          ipa user-add tuser --from-stage
>>>>>>>>>>
>>>>>>>>>>      Is that ok if I implement the command like above or did I
>>>>>>>>>> miss
>>>>>>>>>>      something ?
>>>>>>>>>>
>>>>>>>>>>      regards
>>>>>>>>>>      thierry
>>>>>>>>>
>>>>>>>>> Hmm, no, I think you are right.  We can change --from-stage to
>>>>>>>>> just
>>>>>>>>> Bool
>>>>>>>>> parameter. When it is true, it'd mean that get_dn or pre-callback
>>>>>>>>> should
>>>>>>>>> retrieve the record from stage and use all it's attributes (and
>>>>>>>>> add
>>>>>>>>> standard
>>>>>>>>> default attributes values on top of that).
>>>>>>>>>
>>>>>>>>> Also CC-ing Petr Viktorin for reference.
>>>>>>>
>>>>>>> This operation can't change the user's attributes, can it? I.e., we
>>>>>>> don't
>>>>>>> support something like:
>>>>>>>      ipa user-add tuser --from-stage --phone=123456789
>>>>>>> --email=newemail at example.com
>>>>>>> If this is the case, what's the reason for using user-add for this?
>>>>>>> Wouldn't it
>>>>>>> be better to make this a separate command, say:
>>>>>>>      ipa user-activate tuser
>>>>>>>      ipa user-activate tuser --from-deleted
>>>>>>>      ipa user-activate tuser --from-deleted --to-staged
>>>>
>>>> +1, I would even go as far as having separate commands for staged and
>>>> deleted users, e.g.:
>>>>
>>>>     ipa user-unstage tuser
>>>>     ipa user-undelete tuser
>>>>     ipa user-undelete tuser --to-staged
>>>
>>> A deleted entry has already been active so it contains already set
>>> attributes while the pure staged entries are "almost" empty boxes. But
>>> from an administrator point of view, both staged/deleted entries are
>>> inactive. What would be the advantages of two separated commands ?
>>
>> You just said it yourself: activating/unstaging a user is quite
>> different from undeleting a user. Cramming multiple different
>> operations in a single command is bad design IMHO.
>
> Ok I understand.
> I believe that deleted entries and staged entries will be in the same
> container (provisioning).

The design page mentions "cn=staged 
users,cn=accounts,cn=provisioning,$SUFFIX" and "cn=deleted 
users,cn=accounts,cn=provisioning,$SUFFIX", which are two different 
containers.

> So we may have at least those two possibilities:
>
>   * ipa user-activate tuser [--from-staging|--from-delete]
>   * ipa user-unstage tuser
>     ipa user-undelete tuser
>
>>
>>>
>>>
>>>>
>>>>>>
>>>>>> user-add command does a lot of additional processing besides just
>>>>>> taking the
>>>>>> values and writing them to LDAP. It fills the UID and GID, sets the
>>>>>> non-filled
>>>>>> default attributes like Kerberos attributes, adds user as a member of
>>>>>> ipausers
>>>>>> groups - all that stuff. The same procedures should be also done with
>>>>>> the user
>>>>>> from stage. This is why I proposed to augment user-add.
>>>>>>
>>>>>> If there is a better way, I am open to it.
>>>>>
>>>>> That's not a very good reason to bring in all the CLI/API options,
>>>>> most
>>>>> importantly from the user's perspective. Also you'd have to write
>>>>> extra
>>>>> code to e.g. check the user didn't use the other options, and that
>>>>> tends
>>>>> to get messy quite fast.
>>>>>
>>>>> The common processing should be split out into functions* that both
>>>>> commands would call.
>>>>> (Or methods of the `user` object, which may turn out to be more
>>>>> practical.)
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Jan Cholasta