On 05/29/2014 09:43 AM, 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

You left out "show".

But note that the framework won't allow dashes in the object name, so this would have to be "stage-add", "stageuser-add", "userstage-add", or something like that. (This is because of the way commands are mapped to objects implicitly by name, which I don't think was the best decision, but it is what we have. It may not be very hard to change, though.)

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



--
PetrĀ³

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to