[Freeipa-devel] User life cycle: question regarding the design

[Dmitri Pal]

On 05/30/2014 02:37 AM, Martin Kosek wrote:
> On 05/29/2014 08:14 PM, Dmitri Pal wrote:
>> On 05/29/2014 08:39 AM, Simo Sorce wrote:
>>> On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote:
>>>> On 05/29/2014 05:31 AM, Dmitri Pal wrote:
>>>>> On 05/26/2014 01:49 AM, Martin Kosek wrote:
>>>>>> On 05/23/2014 04:55 PM, Simo Sorce wrote:
>>>>>>> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote:
>>>>>>>> This, I believe, has already been covered, but I'm concerned with the
>>>>>>>> (over)use of active/inactive in this discussion.
>>>>>>>>
>>>>>>>> I think use of "inactive" and "active" to describe users might be
>>>>>>>> confusing since there is already an account enable/disable command.
>>>>>>>> This
>>>>>>>> on top of unlock, are there now 3 possible boolean states a user can
>>>>>>>> be
>>>>>>>> in? locked/unlocked, enabled/disabled, active/inactive, plus
>>>>>>>> deleted/active and staged/active?
>>>>>>>>
>>>>>>> Agree, we should only have "ipa user-unstage <username>" and not call
>>>>>>> this operations with words like active/inactive.
>>>>>>>
>>>>>>> User's in the staging area are not inactive, they are *not* users yet in
>>>>>>> the first place.
>>>>>>>
>>>>>>> Simo.
>>>>>>>
>>>>>> Ok. Let us consolidate the decisions, I think we are now running in circles.
>>>>>> Let me start from Petr3's API proposal which was a functionally complete
>>>>>> proposal and start from there:
>>>>>>
>>>>>> On 05/22/2014 10:47 AM, Petr Viktorin wrote:
>>>>>>> ...
>>>>>>> My proposal would be that the move commands use the verb for the target
>>>>>>> and an
>>>>>>> option for the source, and add/mod use an option for the container:
>>>>>>>
>>>>>>> 1) adding a new user
>>>>>>> (to active)   ipa user-add tuser ...
>>>>>>> (to stage)    ipa user-add tuser --staged ...
>>>>>> Ok.
>>>>>>
>>>>>>> (to deleted)  ipa user-add tuser --deleted ...  (*)
>>>>>> Not needed.
>>>>>>
>>>>>>> 2) moving to main
>>>>>>> (from stage)  ipa user-activate tuser  (**)
>>>>>>> (from del)    ipa user-activate tuser --deleted
>>>>>> We need both, alternative is Simo's proposal:
>>>>>>
>>>>>> ipa user-unstage
>>>>>> ipa user-undelete
>>>>>>
>>>>>> I personally like unstage and undelete commands, I would go with those.
>>>>> Sorry for coming late to the party.
>>>>> I strongly do not like "unstage"
>>>>> This suggests that the user will be removed from staged but does not indicate
>>>>> that the full user will be created.
>>>>> As I suggested elsewhere provision-user or user-provision (or may be even
>>>>> user-add --from-stage) would be better.
>>>> As Petr3 already noted on 05/19/2014 03:19 PM, integrating unstaging operation
>>>> could get messy and would not create the right API. Using a separate call would
>>>> be cleaner. As we see, choosing the right action term has proven very difficult
>>>> - everyone has strong opinion on the command name :-)
>>>>
>>>> I already saw user-activate and user-unstage to be trashed so I am thinking
>>>> what we are left with. I am still fan of user-unstage, user-provision is not
>>>> telling me much more than user-unstage.
>>>>
>>>>>>> 3) moving to deleted
>>>>>>> (from active) ipa user-del tuser
>>>>>> Ok.
>>>>>>
>>>>>>> (from stage)  ipa user-del tuser --staged
>>>>>> IMO staged deleted users should not be moved to deleted container, but simply
>>>>>> permanently deleted. As Simo noted, staged user are not real users, just
>>>>>> incomplete users.
>>>>>>
>>>>>>> 4) moving to stage
>>>>>>> (from active) ipa user-stage tuser
>>>>> This was suggested for completeness.
>>>>> I think we are cutting corners but I would not insist here.
>>>>>
>>>>>>> (from del)    ipa user-stage tuser --deleted
>>>>>> None of the commands are needed for the basic workflow.
>>>>> But this is a valid use case. I created a user, deleted it and want to rebuild
>>>>> it becuase something got corrupted in the original entry. I agree it is not a
>>>>> primary use case but then we should have a ticket to track this RFE for
>>>>> future.
>>>> This was not about cutting corners, this was about what operation makes sense
>>>> and what we should support. Stage was defined as a tree with incomplete user,
>>>> thus this proposal - Simo was not very OK with this workflow.
>>>>
>>>>>>> 5) modifying
>>>>>>> (in active)   ipa user-mod tuser ...
>>>>>> Ok.
>>>>>>
>>>>>>> (in stage)    ipa user-mod tuser --staged ...
>>>>>> Simo did not like this command, I would personally add it. As long as we have
>>>>>> "ipa user-add --staged", we should also have an option to delete and modify
>>>>>> user in staged area.
>>>>>>
>>>>>>> (in del)      ipa user-mod tuser --deleted ...
>>>>>> Not needed.
>>>>>>
>>>>>> Is this acceptable for everyone? If yes, the next step would be for Thierry
>>>>>> to update the design page with new proposals.
>>>>>>
>>>>>> Martin
>>>> Let me try to consolidate again the proposals and changes for the workflow&API
>>>> we have so far:
>>>>
>>>> 1) Manipulating staged users
>>>> - staged users must have UID RDN
>>>> - UID uniqueness plugin should not be enforcing in staging area
>>>> - we do not want it in user plugin as it requires different parameters and
>>>> objectclasses
>>>> - API:
>>>> ipa stage-user-add
>>>> ipa stage-user-mod
>>>> ipa stage-user-find
>>>> ipa stage-user-del
>>>>
>>>> 2) Activating staged user
>>>> - activation will not do MODRDN, it will create a new user in active container
>>>> and then delete the old one (to create right structural objectclass set)
>>>> - for now, we need to allow operator delete any user in staged and add any user
>>>> in active tree
>>>> - API
>>>> ipa stage-user-activate
>>>> - other options mentioned in the past were user-unstage and user-activate
>>>>
>>>> 3) Manipulating deleted users
>>>> - deletion and undeletion will do MODRDN and will use the ACI that Thierry
>>>> implemented
>>>> - API
>>>> ipa user-del
>>>> ipa user-undel OR ipa user-undelete
>>>> - Dmitri mentioned that he would like to see the move from deleted to staged. I
>>>> would do it via flag:
>>>> ipa user-undel --to-stage
>>>>
>>>>
>>>> Does that look better now? Thanks,
>>> Yes, although I do not see the need for --to-stage honestly.
>> I agree we can just leave it as a future ticket.
> I think Simo's thoughts were different - he did not opposed to this part
> because it is too much work (it shouldn't be), but because he did not want that
> part of the workflow. Given the simplicity of this part, I see 2 options:
> 1) Do it and do it together with other API is it just one MODRDN command
> 2) Decide we do not want to do it, i.e. do not file any RFE
>
>> Rest looks OK.
> It should be fine, just one command could done differently to confine it better
> as per Honza's idea:
>
> ipa stageduser-add --from-deleted username

ack
>
> Thierry, you know what to do :-)
>
> Martin


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.