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, Martin _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel