On 05/30/2014 09:24 AM, 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:
As Petr3 already noted on 05/19/2014 03:19 PM, integrating
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
On 05/26/2014 01:49 AM, Martin Kosek wrote:
On 05/23/2014 04:55 PM, Simo Sorce wrote:
Ok. Let us consolidate the decisions, I think we are now running
Let me start from Petr3's API proposal which was a functionally
On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote:
This, I believe, has already been covered, but I'm concerned
Agree, we should only have "ipa user-unstage <username>" and
(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
on top of unlock, are there now 3 possible boolean states a
in? locked/unlocked, enabled/disabled, active/inactive, plus
deleted/active and staged/active?
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.
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
option for the source, and add/mod use an option for the
1) adding a new user
(to active) ipa user-add tuser ...
(to stage) ipa user-add tuser --staged ...
(to deleted) ipa user-add tuser --deleted ... (*)
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:
I personally like unstage and undelete commands, I would go with
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
that the full user will be created.
As I suggested elsewhere provision-user or user-provision (or may
user-add --from-stage) would be better.
- everyone has strong opinion on the command name :-)
I already saw user-activate and user-unstage to be trashed so I am
what we are left with. I am still fan of user-unstage,
user-provision is not
telling me much more than user-unstage.
This was not about cutting corners, this was about what operation
and what we should support. Stage was defined as a tree with
3) moving to deleted
(from active) ipa user-del tuser
IMO staged deleted users should not be moved to deleted
container, but simply
permanently deleted. As Simo noted, staged user are not real
(from stage) ipa user-del tuser --staged
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.
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
(from del) ipa user-stage tuser --deleted
None of the commands are needed for the basic workflow.
thus this proposal - Simo was not very OK with this workflow.
Let me try to consolidate again the proposals and changes for the
(in active) ipa user-mod tuser ...
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
(in stage) ipa user-mod tuser --staged ...
user in staged area.
(in del) ipa user-mod tuser --deleted ...
Is this acceptable for everyone? If yes, the next step would be
to update the design page with new proposals.
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
2) Activating staged user
- activation will not do MODRDN, it will create a new user in
and then delete the old one (to create right structural
- for now, we need to allow operator delete any user in staged and
add any user
in active tree
- other options mentioned in the past were user-unstage and
3) Manipulating deleted users
- deletion and undeletion will do MODRDN and will use the ACI that
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
part of the workflow. Given the simplicity of this part, I see 2
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
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?
either way works for me.
Thierry, you know what to do :-)
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
Freeipa-devel mailing list