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

[thierry bordaz]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140519/c06d2999/attachment.htm>