<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 08/12/2015 05:21 PM, Martin Basti
wrote:<br>
</div>
<blockquote cite="mid:55CB6465.9050903@redhat.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<br>
<br>
<div class="moz-cite-prefix">On 08/12/2015 02:47 PM, Tomas Capek
wrote:<br>
</div>
<blockquote cite="mid:55CB406F.9030501@redhat.com" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 12/08/15 14:22, Martin Basti
wrote:<br>
</div>
<blockquote cite="mid:55CB3A7C.3010201@redhat.com" type="cite">
<br>
<br>
On 08/12/2015 02:08 PM, Tomas Capek wrote: <br>
<blockquote type="cite">On 12/08/15 13:15, David Kupka wrote:
<br>
<blockquote type="cite">On 12/08/15 12:45, thierry bordaz
wrote: <br>
<blockquote type="cite">On 08/12/2015 12:35 PM, Martin
Basti wrote: <br>
<blockquote type="cite"> <br>
<br>
On 08/11/2015 10:40 AM, thierry bordaz wrote: <br>
<blockquote type="cite">On 08/11/2015 09:32 AM, Martin
Basti wrote: <br>
<blockquote type="cite">On 11/08/15 09:17, Jan
Cholasta wrote: <br>
<blockquote type="cite">On 5.8.2015 12:34, thierry
bordaz wrote: <br>
<blockquote type="cite">On 08/05/2015 12:13 PM,
Jan Cholasta wrote: <br>
<blockquote type="cite">Dne 5.8.2015 v 11:55
thierry bordaz napsal(a): <br>
<blockquote type="cite">On 08/05/2015 11:27
AM, Martin Basti wrote: <br>
<blockquote type="cite"> <br>
----- Original Message ----- <br>
From: "thierry bordaz" <a
moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:tbordaz@redhat.com"><a class="moz-txt-link-rfc2396E" href="mailto:tbordaz@redhat.com"><tbordaz@redhat.com></a></a>
<br>
To: "Jan Cholasta" <a
moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:jcholast@redhat.com"><a class="moz-txt-link-rfc2396E" href="mailto:jcholast@redhat.com"><jcholast@redhat.com></a></a>
<br>
Cc: <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:freeipa-devel@redhat.com">freeipa-devel@redhat.com</a>
<br>
Sent: Monday, August 3, 2015 5:34:02 PM
<br>
Subject: Re: [Freeipa-devel] Replace
stageuser-add <br>
--from-delete with <br>
user-undel --to-staged <br>
<br>
On 07/28/2015 12:34 PM, Jan Cholasta
wrote: <br>
<blockquote type="cite">Dne 28.7.2015 v
11:36 Lenka Doudova napsal(a): <br>
<blockquote type="cite"> <br>
Dne 28.7.2015 v 11:27 Jan Cholasta
napsal(a): <br>
<blockquote type="cite">Dne
27.7.2015 v 17:59 Martin Basti
napsal(a): <br>
<blockquote type="cite">On
23/07/15 14:43, Martin Basti
wrote: <br>
<blockquote type="cite">Hello, <br>
<br>
I tried to fix #5145 and I
partially succeeded. <br>
<br>
However, I cannot fix this
part of ticket, where user is
<br>
prompted to <br>
write name and surname. <br>
<br>
$ ipa stageuser-add tuser
--from-delete <br>
First name: this will be
ignored <br>
Last name: this will be also
ignored <br>
------------------------ <br>
Added stage user "tuser" <br>
------------------------ <br>
<br>
As the first name and last
name are mandatory attributes
of <br>
stageuser-add command, but
they are not needed by when
the <br>
--from-delete option is used.
<br>
I would like to ask how to fix
this issue, IMO this will <br>
be huge <br>
hack <br>
in internal API. Or should we
just document this bug as
known <br>
issue <br>
(thierry wrote that this is
not use case that should be
used <br>
often)? <br>
<br>
The best solution would be
separate command, but this
idea <br>
was <br>
rejected in thread
"[Freeipa-devel] User life
cycle: question <br>
regarding the design" <br>
<br>
Regards <br>
Martin^2 <br>
<br>
</blockquote>
Hello, <br>
<br>
as was mentioned before, we have
issue with current <br>
internal API <br>
and the <br>
stageuser-add --from-delete
command. <br>
<br>
We discussed this today, and we
did not find a nice way how <br>
to fix <br>
it, <br>
so we propose this (which is IMO
the best solution): <br>
<br>
* stageuser-add --from-delete
should be deprecated <br>
</blockquote>
+1 <br>
<br>
<blockquote type="cite">* create
new option for user-undel:
used-undel --to-staged (or <br>
create <br>
new command) that will handle
moving deleted users to staged <br>
area as <br>
--from-delete did. <br>
</blockquote>
Make it new command please. <br>
<br>
<blockquote type="cite">Instead of
stageuser-add and option
--from-delete, which work <br>
totally <br>
different, the command
user-undel does similar
operation than <br>
stage-user <br>
--from-delete, it just uses
different container. <br>
</blockquote>
NACK on stuffing everything into a
single command just <br>
because it <br>
does <br>
something similar. <br>
</blockquote>
How about making it a
'stageuser-undel'? The 'user-undel'
moves <br>
preserved user to active, so the
'stageuser-undel' would move <br>
preserved <br>
to staged. The action is similar,
but has slightly different <br>
specifics <br>
(which attributes are preserved
etc.), and for me the <br>
'stageuser-undel' <br>
feels more natural than 'user-undel
--to-staged' since it's <br>
basically <br>
the same as there is 'stageuser-add'
for creating a staged <br>
user, not <br>
'user-add --to-staged'. It would be
in the same style as all the <br>
other <br>
commands concerning operations with
users in staged container. <br>
</blockquote>
Well, user-undel is the opposite of
user-del, and stageuser-undel <br>
should be the opposite of
stageuser-del. The stageuser-undel <br>
you are <br>
suggesting is not. <br>
<br>
Also I'm not sure if we want to
(always) remove the deleted <br>
user once <br>
a staged user is created from it, but
-undel behaves like that. <br>
<br>
I don't think the command should be
limited to deleted users <br>
only. <br>
Active and deleted users share the
same namespace, so it is an <br>
arbitrary limitation. <br>
</blockquote>
preserved users has been valid active
user. In that sense <br>
active/preserved are managed by a same
set of CLI <br>
(user-find,user-del,user-show) because a
preserved user is a <br>
'user'. So <br>
I would vote for continuing with a
'user-*' commands and use <br>
'user-undel <br>
--to-stage'. <br>
<br>
But then if we will make any
incompatible change between <br>
"user-undel" <br>
and "user-undel --to-stage" we may hit
this issue again. I <br>
agree with <br>
Honza, this should be a separate
command. <br>
</blockquote>
What do you mean 'incompatible change' ? <br>
<br>
--to-stage option would only select a
different container that the <br>
'Active' one ? <br>
</blockquote>
<br>
That's not sufficient. The command should do
the reverse of <br>
stageuser-activate, which is ADD and DELETE,
possibly with some <br>
modifications of the entry between them, not
MODRDN like <br>
user-undel does. <br>
<br>
</blockquote>
That is a good point. Do we need to modify
anything from a deleted <br>
entry <br>
to a add it in the stage container. <br>
Already delete entry have been purged of
several values (password, <br>
krb <br>
keys, membership,..) do you think of other
attributes to remove ? <br>
<br>
IIRC the use case is a support engineer who
activated too early an <br>
entry. So you are right he wants to unactivate
it. A question is does <br>
the unactivation requires more modifications
than the one did by <br>
'user-del --preserve'. Note that we can not
retrieve the attribute <br>
values when the entry was activated from
stage. <br>
</blockquote>
<br>
I don't know if any modifications are needed ATM
(doesn't mean <br>
there can't be any in the future), but the point
is that if you are <br>
creating object A from object B using operation
X, you should be <br>
creating object B from object A using the
reverse of operation X, <br>
otherwise there *will* be inconsistencies, and
we don't want that. <br>
<br>
</blockquote>
+1 <br>
I agree with this <br>
<br>
</blockquote>
So my understanding is that you think a new verb
should be created to <br>
allow: 'Active' -> 'Stage' <br>
I do not recall why this was not discussed or if it
as already been <br>
rejected. <br>
<br>
I like the idea and I think it could be useful to
Support Engineer. <br>
Now I am not sure we want to make 'easy' the action
to 'unactivate' a <br>
user (currently it requires two operations). <br>
In your opinion, does it replace 'stageuser-add
--from-delete' or <br>
'user-undel --to-stage' ? or is it an additional
subcommand. <br>
Also, activate/unactivate is not a NULL operation.
Some values has <br>
been changed (uid,gid,uniqueuiid...) and some values
will be lost <br>
(membership). <br>
<br>
About the verb, this is not because the previous
action is 'activate' <br>
that we should use 'unactivate'. For example, Thomas
raised the point <br>
that after 'user-del', 'user-restore' would have
been more user <br>
friendly than 'user-undel' <br>
<br>
Thanks <br>
thierry <br>
<br>
</blockquote>
We had discussion off-list discussion, and result is
following proposal: <br>
<br>
* remove 'stageuser-add --from-delete' <br>
* add new command: 'user-stage' <br>
<br>
the user-stage command will move both deleted or
active users to <br>
staged area. <br>
$ user-stage <deleted_user> <br>
replaces the stage-user --from-delete, keeps the same
behavior <br>
<br>
$ user-stage <active_user> <br>
this is stretch goal, nice to have, but I don't know
how easy is to <br>
implement this <br>
<br>
For better visualization, here is link to our board
screen <br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://pvoborni.fedorapeople.org/images/user-lifecycle.jpg">https://pvoborni.fedorapeople.org/images/user-lifecycle.jpg</a>
<br>
<br>
Thierry, do you agree with this? <br>
Martin^2 <br>
</blockquote>
<br>
<br>
Hello, <br>
<br>
I really like the idea (as well as the drawing) of
having the same cli <br>
for both active/deleted user. <br>
About the exact verb 'user-stage', I am always bad at
this exercise and <br>
it would be great to have Thomas ack on that. <br>
<br>
Just a question about the other verbs
user-disable/user-enable. I know <br>
they are doing something different but do you think
there is a risk of <br>
confusion for admin when he should do user-stage or
user-disable ? <br>
<br>
thanks <br>
thierry <br>
<br>
<br>
<br>
</blockquote>
<br>
Adding Tomas to the loop. <br>
</blockquote>
Hello everyone, <br>
<br>
I probably don't have all the information and perhaps
cannot see all possible side effects but on the handover
session for this feature, I was concerned that some commands
did not match in GUI and in CLI (restore, undel). <br>
<br>
Also, from the UX perspective, I thought it would be more
friendly to have symmetrical commands and not confuse users
with two delete modes as in "do you want to mock-delete the
user or delete delete it?" <br>
<br>
Therefore, I proposed to have two simple pairs of commands,
also reflected in the UI: <br>
<br>
"add" and "delete" - for just adding and completely
removing users <br>
<br>
"retire" and "restore" - for just putting a user to or
taking it out of the user "archive" <br>
<br>
</blockquote>
Sounds good, but we will not change all commands. <br>
</blockquote>
<br>
Sure, I made this proposal only for the user lifecycle feature.
Perhaps some commands could be aliases if it would make it
easier to introduce them...<br>
<br>
<blockquote cite="mid:55CB3A7C.3010201@redhat.com" type="cite">
<br>
<blockquote type="cite">as for the "--from-delete" option , I
think the proposed "user-stage" overlaps a little with the
existing "stageuser-*" commands. As the command would move a
user to the initial state of the lifecycle, be it an active
or retired user, I'd try to emphasize the fact by proposing
a similar but perhaps more cogent "user-restage". <br>
<br>
Do you think it would work? <br>
</blockquote>
How about case, when user was created via 'user-add', then
'user-restage' may confuse users, because that user hasn't
been in stage area. <br>
<br>
</blockquote>
I guess it depends on whether the user is aware of the lifecycle
feature as the stage would be implied even if some users start
as active.<br>
<br>
But we could add to the symmetry of the commands:<br>
<br>
<b>add - delete</b> (manipulates active or staged users)<br>
<b><b>activate - deactivate</b> </b>(between staged and active
users)<b><br>
retire - restore</b> (between active and archived users)<br>
<br>
<b>retire - restage </b>(between staged and archived users)<br>
</blockquote>
We cannot change commands that already exist, it would be more
pain than gain.<br>
<br>
<blockquote cite="mid:55CB406F.9030501@redhat.com" type="cite"> <br>
Admittedly, both of the cases in the last pair seem weird and
rare to be used. But if the "retire" action ultimately remains
undefined for staged users, I think it would still be fine as
"restage" pushes a user through two states back :-)<br>
</blockquote>
And I'm quite lost in what you wrote. We have user-* and
stageuser-* commads<br>
<blockquote cite="mid:55CB406F.9030501@redhat.com" type="cite"> <br>
Also, if we have the "deactivate" action for active users, I'd
try to make it clear what are the practical differences between
"retire" and "deactivate" in this setup.<br>
</blockquote>
We have:<br>
activate: stageuser-activate<br>
deactivate: user-del --preserve<br>
retire: planned user-stage (active user)<br>
restore: user-undel (applies only to users)<br>
restage: planned user-stage (deleted user)<br>
staged->archived user: N/A<br>
<blockquote cite="mid:55CB406F.9030501@redhat.com" type="cite"> <br>
Cheers,<br>
Tomas<br>
<br>
<br>
<br>
<blockquote cite="mid:55CB3A7C.3010201@redhat.com" type="cite">Martin^2
<br>
<blockquote type="cite"> <br>
Tomas <br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Tomáš Čapek
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:tcapek@redhat.com">tcapek@redhat.com</a>
IRC Nick: tcapek
Team name: Customer Content Services (CCS)</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
It looks like there is still no consensus about the name.<br>
<br>
I would like to name it 'user-stage', because we cannot change name
of already implemented commands, there is no way to use naming
schema that Tomas proposed.<br>
<br>
Is there any objections? I will send patch next week.<br>
<br>
Martin^2<br>
</body>
</html>