[Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

[Jan Cholasta]

Dne 5.8.2015 v 11:55 thierry bordaz napsal(a):
> On 08/05/2015 11:27 AM, Martin Basti wrote:
>>
>> ----- Original Message -----
>> From: "thierry bordaz" <tbordaz at redhat.com>
>> To: "Jan Cholasta" <jcholast at redhat.com>
>> Cc: freeipa-devel at redhat.com
>> Sent: Monday, August 3, 2015 5:34:02 PM
>> Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with
>> user-undel --to-staged
>>
>> On 07/28/2015 12:34 PM, Jan Cholasta wrote:
>>> Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a):
>>>>
>>>> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a):
>>>>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a):
>>>>>> On 23/07/15 14:43, Martin Basti wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I tried to fix #5145 and I partially succeeded.
>>>>>>>
>>>>>>> However, I cannot fix this part of ticket, where user is prompted to
>>>>>>> write name and surname.
>>>>>>>
>>>>>>> $ ipa stageuser-add tuser --from-delete
>>>>>>> First name: this will be ignored
>>>>>>> Last name: this will be also ignored
>>>>>>> ------------------------
>>>>>>> Added stage user "tuser"
>>>>>>> ------------------------
>>>>>>>
>>>>>>> As the first name and last name are mandatory attributes of
>>>>>>> stageuser-add command, but they are not needed by when the
>>>>>>> --from-delete option is used.
>>>>>>> I would like to ask how to fix this issue, IMO this will be huge
>>>>>>> hack
>>>>>>> in internal API. Or should we just document this bug as known issue
>>>>>>> (thierry wrote that this is not use case that should be used often)?
>>>>>>>
>>>>>>> The best solution would be separate command, but this idea was
>>>>>>> rejected in thread "[Freeipa-devel] User life cycle: question
>>>>>>> regarding the design"
>>>>>>>
>>>>>>> Regards
>>>>>>> Martin^2
>>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> as was mentioned before, we have issue with current internal API
>>>>>> and the
>>>>>> stageuser-add --from-delete command.
>>>>>>
>>>>>> We discussed this today, and we did not find a nice way how to fix
>>>>>> it,
>>>>>> so we propose this (which is IMO the best solution):
>>>>>>
>>>>>> * stageuser-add --from-delete should be deprecated
>>>>> +1
>>>>>
>>>>>> * create new option for user-undel: used-undel --to-staged  (or
>>>>>> create
>>>>>> new command) that will handle moving deleted users to staged area as
>>>>>> --from-delete did.
>>>>> Make it new command please.
>>>>>
>>>>>> Instead of stageuser-add and option --from-delete, which work totally
>>>>>> different, the command user-undel does similar operation than
>>>>>> stage-user
>>>>>> --from-delete, it just uses different container.
>>>>> NACK on stuffing everything into a single command just because it does
>>>>> something similar.
>>>> How about making it a 'stageuser-undel'? The 'user-undel' moves
>>>> preserved user to active, so the 'stageuser-undel' would move preserved
>>>> to staged. The action is similar, but has slightly different specifics
>>>> (which attributes are preserved etc.), and for me the 'stageuser-undel'
>>>> feels more natural than 'user-undel --to-staged' since it's basically
>>>> the same as there is 'stageuser-add' for creating a staged user, not
>>>> 'user-add --to-staged'. It would be in the same style as all the other
>>>> commands concerning operations with users in staged container.
>>> Well, user-undel is the opposite of user-del, and stageuser-undel
>>> should be the opposite of stageuser-del. The stageuser-undel you are
>>> suggesting is not.
>>>
>>> Also I'm not sure if we want to (always) remove the deleted user once
>>> a staged user is created from it, but -undel behaves like that.
>>>
>>> I don't think the command should be limited to deleted users only.
>>> Active and deleted users share the same namespace, so it is an
>>> arbitrary limitation.
>> preserved users has been valid active user. In that sense
>> active/preserved are managed by a same set of CLI
>> (user-find,user-del,user-show) because a preserved user is a 'user'. So
>> I would vote for continuing with a 'user-*' commands and use 'user-undel
>> --to-stage'.
>>
>> But then if we will make any incompatible change between "user-undel"
>> and "user-undel --to-stage" we may hit this issue again. I agree with
>> Honza, this should be a separate command.
> What do you mean 'incompatible change' ?
>
> --to-stage option would only select a different container that the
> 'Active' one ?

That's not sufficient. The command should do the reverse of 
stageuser-activate, which is ADD and DELETE, possibly with some 
modifications of the entry between them, not MODRDN like user-undel does.

-- 
Jan Cholasta