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

[thierry bordaz]

On 05/30/2014 03:32 PM, Jan Cholasta wrote:
> On 30.5.2014 15:24, 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?
>
> stageduser-undel suggests it's opposite of stageduser-del, which it is 
> not. An alternative would be something like 
> stageduser-add-from-deleted, but that's really long, hence my proposal 
> to use stageduser-add.

I have also a preference for '--from-deleted' option rather than a new 
verb. IMHO 'Delete' -> 'Stage' would be a quite rare and using an option 
shows that it is a special case.



Regarding generate attribute, Delete users have final unique value 
(ipaUniqueID, uidNumber..) should we return the values to standard 
"staging" values ('autogenerate', -1) ? I believe yes.

Also a Deleted user is booking an ipaUniqueID/uidNumber value, so an 
other active entry can not use these values. If we move that user out of 
the scope of attribute uniqueness, an other staging entry may pick up 
these values. Is it a risk ?
For example, if on a machine I authenticate with entry A that contains 
values identical from old entry B, may I get the entry B authorisations 
on an other machine (where deletion of entry B has not yet occur) ?

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