On 08/11/2015 09:32 AM, Martin Basti wrote:
So my understanding is that you think a new verb should be created to
allow: 'Active' -> 'Stage'
I do not recall why this was not discussed or if it as already been
On 11/08/15 09:17, Jan Cholasta wrote:
On 5.8.2015 12:34, thierry bordaz wrote:
On 08/05/2015 12:13 PM, Jan Cholasta wrote:
That is a good point. Do we need to modify anything from a deleted
Dne 5.8.2015 v 11:55 thierry bordaz napsal(a):
On 08/05/2015 11:27 AM, Martin Basti wrote:
----- Original Message -----
From: "thierry bordaz" <tbor...@redhat.com>
To: "Jan Cholasta" <jchol...@redhat.com>
Sent: Monday, August 3, 2015 5:34:02 PM
Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete
On 07/28/2015 12:34 PM, Jan Cholasta wrote:
Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a):
Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a):
Dne 27.7.2015 v 17:59 Martin Basti napsal(a):
On 23/07/15 14:43, Martin Basti wrote:
I tried to fix #5145 and I partially succeeded.
However, I cannot fix this part of ticket, where user is
write name and surname.
$ ipa stageuser-add tuser --from-delete
First name: this will be ignored
Last name: this will be also ignored
Added stage user "tuser"
As the first name and last name are mandatory attributes of
stageuser-add command, but they are not needed by when the
--from-delete option is used.
I would like to ask how to fix this issue, IMO this will be
in internal API. Or should we just document this bug as known
(thierry wrote that this is not use case that should be used
The best solution would be separate command, but this idea was
rejected in thread "[Freeipa-devel] User life cycle: question
regarding the design"
as was mentioned before, we have issue with current internal API
stageuser-add --from-delete command.
We discussed this today, and we did not find a nice way how
so we propose this (which is IMO the best solution):
* stageuser-add --from-delete should be deprecated
* create new option for user-undel: used-undel --to-staged (or
new command) that will handle moving deleted users to staged
Make it new command please.
Instead of stageuser-add and option --from-delete, which work
different, the command user-undel does similar operation than
--from-delete, it just uses different container.
NACK on stuffing everything into a single command just because it
How about making it a 'stageuser-undel'? The 'user-undel' moves
preserved user to active, so the 'stageuser-undel' would move
to staged. The action is similar, but has slightly different
(which attributes are preserved etc.), and for me the
feels more natural than 'user-undel --to-staged' since it's
the same as there is 'stageuser-add' for creating a staged
'user-add --to-staged'. It would be in the same style as all the
commands concerning operations with users in staged container.
Well, user-undel is the opposite of user-del, and stageuser-undel
should be the opposite of stageuser-del. The stageuser-undel you
suggesting is not.
Also I'm not sure if we want to (always) remove the deleted user
a staged user is created from it, but -undel behaves like that.
I don't think the command should be limited to deleted users only.
Active and deleted users share the same namespace, so it is an
preserved users has been valid active user. In that sense
active/preserved are managed by a same set of CLI
(user-find,user-del,user-show) because a preserved user is a
I would vote for continuing with a 'user-*' commands and use
But then if we will make any incompatible change between
and "user-undel --to-stage" we may hit this issue again. I agree
Honza, this should be a separate command.
What do you mean 'incompatible change' ?
--to-stage option would only select a different container that the
'Active' one ?
That's not sufficient. The command should do the reverse of
stageuser-activate, which is ADD and DELETE, possibly with some
modifications of the entry between them, not MODRDN like user-undel
to a add it in the stage container.
Already delete entry have been purged of several values (password, krb
keys, membership,..) do you think of other attributes to remove ?
IIRC the use case is a support engineer who activated too early an
entry. So you are right he wants to unactivate it. A question is does
the unactivation requires more modifications than the one did by
'user-del --preserve'. Note that we can not retrieve the attribute
values when the entry was activated from stage.
I don't know if any modifications are needed ATM (doesn't mean there
can't be any in the future), but the point is that if you are
creating object A from object B using operation X, you should be
creating object B from object A using the reverse of operation X,
otherwise there *will* be inconsistencies, and we don't want that.
I agree with this
I like the idea and I think it could be useful to Support Engineer. Now
I am not sure we want to make 'easy' the action to 'unactivate' a user
(currently it requires two operations).
In your opinion, does it replace 'stageuser-add --from-delete' or
'user-undel --to-stage' ? or is it an additional subcommand.
Also, activate/unactivate is not a NULL operation. Some values has been
changed (uid,gid,uniqueuiid...) and some values will be lost (membership).
About the verb, this is not because the previous action is 'activate'
that we should use 'unactivate'. For example, Thomas raised the point
that after 'user-del', 'user-restore' would have been more user friendly
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code