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

Thu May 29 08:15:51 UTC 2014

On 29.5.2014 09:43, 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

I think this has to be stageduser-add, etc., since the framework does 
not allow object names with multiple words.

>
> 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

I would prefer if anything related to staged users was confined to the 
stage-user/stageduser plugin. So maybe something like this:

ipa stage-user-add --from-deleted=username

>
>
> Does that look better now? Thanks,
> Martin
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
>

-- 
Jan Cholasta