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

[Rob Crittenden]

Petr Viktorin wrote:
> On 05/30/2014 08: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
> 
> Do we want that to take all of stageduser-add's options?
> Should we use somrthing like stageduser-undel instead?

I concur, though it should probably be stageduser-mod --undelete to keep
with the CRUD model.

rob