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

Wed Aug 12 15:21:09 UTC 2015


On 08/12/2015 02:47 PM, Tomas Capek wrote:
> On 12/08/15 14:22, Martin Basti wrote:
>>
>>
>> On 08/12/2015 02:08 PM, Tomas Capek wrote:
>>> On 12/08/15 13:15, David Kupka wrote:
>>>> On 12/08/15 12:45, thierry bordaz wrote:
>>>>> On 08/12/2015 12:35 PM, Martin Basti wrote:
>>>>>>
>>>>>>
>>>>>> 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
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> I really like the idea (as well as the drawing) of having the same 
>>>>> cli
>>>>> for both active/deleted user.
>>>>> About the exact verb 'user-stage', I am always bad at this 
>>>>> exercise and
>>>>> it would be great to have Thomas ack on that.
>>>>>
>>>>> Just a question about the other verbs user-disable/user-enable. I 
>>>>> know
>>>>> they are doing something different but do you think there is a 
>>>>> risk of
>>>>> confusion for admin when he should do user-stage or user-disable ?
>>>>>
>>>>> thanks
>>>>> thierry
>>>>>
>>>>>
>>>>>
>>>>
>>>> Adding Tomas to the loop.
>>> Hello everyone,
>>>
>>>   I probably don't have all the information and perhaps cannot see 
>>> all possible side effects but on the handover session for this 
>>> feature, I was concerned that some commands did not match in GUI and 
>>> in CLI (restore, undel).
>>>
>>> Also, from the UX perspective, I thought it would be more friendly 
>>> to have symmetrical commands and not confuse users with two delete 
>>> modes as in "do you want to mock-delete the user or delete delete it?"
>>>
>>> Therefore, I proposed to have two simple pairs of commands, also 
>>> reflected in the UI:
>>>
>>> "add" and "delete"  - for just adding and completely removing users
>>>
>>> "retire" and "restore" - for just putting a user to or taking it out 
>>> of the user "archive"
>>>
>> Sounds good, but we will not change all commands.
>
> Sure, I made this proposal only for the user lifecycle feature. 
> Perhaps some commands could be aliases if it would make it easier to 
> introduce them...
>
>>
>>> as for the "--from-delete" option , I think the proposed 
>>> "user-stage" overlaps a little with the existing "stageuser-*" 
>>> commands. As the command would move a user to the initial state of 
>>> the lifecycle, be it an active or retired user, I'd try to emphasize 
>>> the fact by proposing a similar but perhaps more cogent "user-restage".
>>>
>>> Do you think it would work?
>> How about case, when user was created via 'user-add',  then 
>> 'user-restage' may confuse users, because that user hasn't been in 
>> stage area.
>>
> I guess it depends on whether the user is aware of the lifecycle 
> feature as the stage would be implied even if some users start as active.
>
> But we could add to the symmetry of the commands:
>
> *add - delete* (manipulates active or staged users)
> **activate - deactivate* *(between staged and active users)*
> retire - restore* (between active and archived users)
>
> *retire - restage *(between staged and archived users)
We cannot change  commands that already exist, it would be more pain 
than gain.

>
> Admittedly, both of the cases in the last pair seem weird and rare to 
> be used. But if the "retire" action ultimately remains undefined for 
> staged users, I think it would still be fine as "restage" pushes a 
> user through two states back :-)
And I'm quite lost in what you wrote. We have user-* and stageuser-* commads
>
> Also, if we have the "deactivate" action for active users, I'd try to 
> make it clear what are the practical differences between "retire" and 
> "deactivate" in this setup.
We have:
activate: stageuser-activate
deactivate: user-del --preserve
retire: planned user-stage (active user)
restore: user-undel (applies only to users)
restage: planned user-stage (deleted user)
staged->archived user: N/A
>
> Cheers,
> Tomas
>
>
>
>> Martin^2
>>>
>>> Tomas
>>>
>>>
>>
>
>
> -- 
> Tomáš Čapek
> tcapek at redhat.com
> IRC Nick: tcapek
> Team name: Customer Content Services (CCS)

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