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

Wed Aug 12 10:35:16 UTC 2015

On 08/11/2015 10:40 AM, thierry bordaz wrote:
> On 08/11/2015 09:32 AM, Martin Basti wrote:
>> On 11/08/15 09:17, Jan Cholasta wrote:
>>> On 5.8.2015 12:34, thierry bordaz wrote:
>>>> On 08/05/2015 12:13 PM, Jan Cholasta wrote:
>>>>> 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.
>>>>>
>>>> That is a good point. Do we need to modify anything from a deleted 
>>>> entry
>>>> to a add it in the stage container.
>>>> Already delete entry have been purged of several values (password, krb
>>>> keys, membership,..) do you think of other attributes to remove ?
>>>>
>>>> IIRC the use case is a support engineer who activated too early an
>>>> entry. So you are right he wants to unactivate it. A question is does
>>>> the unactivation requires more modifications than the one did by
>>>> 'user-del --preserve'. Note that we can not retrieve the attribute
>>>> values when the entry was activated from stage.
>>>
>>> I don't know if any modifications are needed ATM (doesn't mean there 
>>> can't be any in the future), but the point is that if you are 
>>> creating object A from object B using operation X, you should be 
>>> creating object B from object A using the reverse of operation X, 
>>> otherwise there *will* be inconsistencies, and we don't want that.
>>>
>> +1
>> I agree with this
>>
> So my understanding is that you think a new verb should be created to 
> allow: 'Active' -> 'Stage'
> I do not recall why this was not discussed or if it as already been 
> rejected.
>
> I like the idea and I think it could be useful to Support Engineer. 
> Now I am not sure we want to make 'easy' the action to 'unactivate' a 
> user (currently it requires two operations).
> In your opinion, does it replace 'stageuser-add --from-delete' or 
> 'user-undel --to-stage' ? or is it an additional subcommand.
> Also, activate/unactivate is not a NULL operation. Some values has 
> been changed (uid,gid,uniqueuiid...) and some values will be lost 
> (membership).
>
> About the verb, this is not because the previous action is 'activate' 
> that we should use 'unactivate'. For example, Thomas raised the point 
> that after 'user-del', 'user-restore' would have been more user 
> friendly than 'user-undel'
>
> Thanks
> thierry
>
We had discussion off-list discussion, and result is following proposal:

* remove 'stageuser-add --from-delete'
* add new command: 'user-stage'

the user-stage command will move both deleted or active users to staged 
area.
$ user-stage <deleted_user>
replaces the stage-user --from-delete, keeps the same behavior

$ user-stage <active_user>
this is stretch goal, nice to have, but I don't know how easy is to 
implement this

For better visualization, here is link to our board screen 
https://pvoborni.fedorapeople.org/images/user-lifecycle.jpg

Thierry, do you agree with this?
Martin^2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20150812/874acb44/attachment.htm>