Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-08-14 Thread Martin Basti



On 08/12/2015 05:21 PM, Martin Basti wrote:



On 08/12/2015 02:47 PM, Tomas Capek wrote:

On 12/08/15 14:22, Martin Basti wrote:



On 08/12/2015 02:08 PM, Tomas Capek wrote:

On 12/08/15 13:15, David Kupka wrote:

On 12/08/15 12:45, thierry bordaz wrote:

On 08/12/2015 12:35 PM, Martin Basti wrote:



On 08/11/2015 10:40 AM, thierry bordaz wrote:

On 08/11/2015 09:32 AM, Martin Basti wrote:

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:

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
Cc: freeipa-devel@redhat.com
Sent: Monday, August 3, 2015 5:34:02 PM
Subject: Re: [Freeipa-devel] Replace stageuser-add
--from-delete with
user-undel --to-staged

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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where 
user is

prompted to
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 huge
hack
in internal API. Or should we just document this bug 
as known

issue
(thierry wrote that this is not use case that should 
be used

often)?

The best solution would be separate command, but 
this idea

was
rejected in thread [Freeipa-devel] User life cycle: 
question

regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current
internal API
and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice 
way how

to fix
it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated

+1

* create new option for user-undel: used-undel 
--to-staged (or

create
new command) that will handle moving deleted users to 
staged

area as
--from-delete did.

Make it new command please.

Instead of stageuser-add and option --from-delete, 
which work

totally
different, the command user-undel does similar 
operation than

stage-user
--from-delete, it just uses different container.

NACK on stuffing everything into a single command just
because it
does
something similar.
How about making it a 'stageuser-undel'? The 
'user-undel' moves
preserved user to active, so the 'stageuser-undel' 
would move

preserved
to staged. The action is similar, but has slightly 
different

specifics
(which attributes are preserved etc.), and for me the
'stageuser-undel'
feels more natural than 'user-undel --to-staged' since 
it's

basically
the same as there is 'stageuser-add' for creating a staged
user, not
'user-add --to-staged'. It would be in the same style 
as all the

other
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 are
suggesting is not.

Also I'm not sure if we want to (always) remove the deleted
user once
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

arbitrary limitation.

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
'user'. So
I would vote for continuing with a 'user-*' commands and use
'user-undel
--to-stage'.

But then if we will make any incompatible change between
user-undel
and user-undel --to-stage we may hit this issue again. I
agree with
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 does.

That is a good point. Do we need to modify anything from a 
deleted

entry
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

Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-08-12 Thread David Kupka

On 12/08/15 12:45, thierry bordaz wrote:

On 08/12/2015 12:35 PM, Martin Basti wrote:



On 08/11/2015 10:40 AM, thierry bordaz wrote:

On 08/11/2015 09:32 AM, Martin Basti wrote:

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:

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
Cc: freeipa-devel@redhat.com
Sent: Monday, August 3, 2015 5:34:02 PM
Subject: Re: [Freeipa-devel] Replace stageuser-add
--from-delete with
user-undel --to-staged

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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is
prompted to
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 huge
hack
in internal API. Or should we just document this bug as known
issue
(thierry wrote that this is not use case that should be used
often)?

The best solution would be separate command, but this idea
was
rejected in thread [Freeipa-devel] User life cycle: question
regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current
internal API
and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how
to fix
it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated

+1


* create new option for user-undel: used-undel --to-staged (or
create
new command) that will handle moving deleted users to staged
area as
--from-delete did.

Make it new command please.


Instead of stageuser-add and option --from-delete, which work
totally
different, the command user-undel does similar operation than
stage-user
--from-delete, it just uses different container.

NACK on stuffing everything into a single command just
because it
does
something similar.

How about making it a 'stageuser-undel'? The 'user-undel' moves
preserved user to active, so the 'stageuser-undel' would move
preserved
to staged. The action is similar, but has slightly different
specifics
(which attributes are preserved etc.), and for me the
'stageuser-undel'
feels more natural than 'user-undel --to-staged' since it's
basically
the same as there is 'stageuser-add' for creating a staged
user, not
'user-add --to-staged'. It would be in the same style as all the
other
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 are
suggesting is not.

Also I'm not sure if we want to (always) remove the deleted
user once
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
arbitrary limitation.

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
'user'. So
I would vote for continuing with a 'user-*' commands and use
'user-undel
--to-stage'.

But then if we will make any incompatible change between
user-undel
and user-undel --to-stage we may hit this issue again. I
agree with
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 does.


That is a good point. Do we need to modify anything from a deleted
entry
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

Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-08-12 Thread thierry bordaz

On 08/12/2015 12:35 PM, Martin Basti wrote:



On 08/11/2015 10:40 AM, thierry bordaz wrote:

On 08/11/2015 09:32 AM, Martin Basti wrote:

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:

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
Cc: freeipa-devel@redhat.com
Sent: Monday, August 3, 2015 5:34:02 PM
Subject: Re: [Freeipa-devel] Replace stageuser-add 
--from-delete with

user-undel --to-staged

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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is
prompted to
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 huge

hack
in internal API. Or should we just document this bug as known
issue
(thierry wrote that this is not use case that should be used
often)?

The best solution would be separate command, but this idea 
was

rejected in thread [Freeipa-devel] User life cycle: question
regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current 
internal API

and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how 
to fix

it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated

+1

* create new option for user-undel: used-undel --to-staged  
(or

create
new command) that will handle moving deleted users to staged
area as
--from-delete did.

Make it new command please.


Instead of stageuser-add and option --from-delete, which work
totally
different, the command user-undel does similar operation than
stage-user
--from-delete, it just uses different container.
NACK on stuffing everything into a single command just 
because it

does
something similar.

How about making it a 'stageuser-undel'? The 'user-undel' moves
preserved user to active, so the 'stageuser-undel' would move
preserved
to staged. The action is similar, but has slightly different
specifics
(which attributes are preserved etc.), and for me the
'stageuser-undel'
feels more natural than 'user-undel --to-staged' since it's 
basically
the same as there is 'stageuser-add' for creating a staged 
user, not

'user-add --to-staged'. It would be in the same style as all the
other
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 are

suggesting is not.

Also I'm not sure if we want to (always) remove the deleted 
user once

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
arbitrary limitation.

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 
'user'. So

I would vote for continuing with a 'user-*' commands and use
'user-undel
--to-stage'.

But then if we will make any incompatible change between 
user-undel
and user-undel --to-stage we may hit this issue again. I 
agree with

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 does.


That is a good point. Do we need to modify anything from a deleted 
entry

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

Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-08-12 Thread Martin Basti



On 08/11/2015 10:40 AM, thierry bordaz wrote:

On 08/11/2015 09:32 AM, Martin Basti wrote:

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:

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
Cc: freeipa-devel@redhat.com
Sent: Monday, August 3, 2015 5:34:02 PM
Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete 
with

user-undel --to-staged

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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is
prompted to
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 
huge

hack
in internal API. Or should we just document this bug as known
issue
(thierry wrote that this is not use case that should be used
often)?

The best solution would be separate command, but this idea was
rejected in thread [Freeipa-devel] User life cycle: question
regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current internal 
API

and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how 
to fix

it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated

+1


* create new option for user-undel: used-undel --to-staged  (or
create
new command) that will handle moving deleted users to staged
area as
--from-delete did.

Make it new command please.


Instead of stageuser-add and option --from-delete, which work
totally
different, the command user-undel does similar operation than
stage-user
--from-delete, it just uses different container.
NACK on stuffing everything into a single command just 
because it

does
something similar.

How about making it a 'stageuser-undel'? The 'user-undel' moves
preserved user to active, so the 'stageuser-undel' would move
preserved
to staged. The action is similar, but has slightly different
specifics
(which attributes are preserved etc.), and for me the
'stageuser-undel'
feels more natural than 'user-undel --to-staged' since it's 
basically
the same as there is 'stageuser-add' for creating a staged 
user, not

'user-add --to-staged'. It would be in the same style as all the
other
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 are

suggesting is not.

Also I'm not sure if we want to (always) remove the deleted 
user once

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
arbitrary limitation.

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 
'user'. So

I would vote for continuing with a 'user-*' commands and use
'user-undel
--to-stage'.

But then if we will make any incompatible change between 
user-undel
and user-undel --to-stage we may hit this issue again. I agree 
with

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 does.


That is a good point. Do we need to modify anything from a deleted 
entry

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

Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-08-12 Thread Tomas Capek

On 12/08/15 13:15, David Kupka wrote:

On 12/08/15 12:45, thierry bordaz wrote:

On 08/12/2015 12:35 PM, Martin Basti wrote:



On 08/11/2015 10:40 AM, thierry bordaz wrote:

On 08/11/2015 09:32 AM, Martin Basti wrote:

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:

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
Cc: freeipa-devel@redhat.com
Sent: Monday, August 3, 2015 5:34:02 PM
Subject: Re: [Freeipa-devel] Replace stageuser-add
--from-delete with
user-undel --to-staged

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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is
prompted to
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 huge
hack
in internal API. Or should we just document this bug as 
known

issue
(thierry wrote that this is not use case that should be 
used

often)?

The best solution would be separate command, but this idea
was
rejected in thread [Freeipa-devel] User life cycle: 
question

regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current
internal API
and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how
to fix
it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated

+1

* create new option for user-undel: used-undel 
--to-staged (or

create
new command) that will handle moving deleted users to staged
area as
--from-delete did.

Make it new command please.

Instead of stageuser-add and option --from-delete, which 
work

totally
different, the command user-undel does similar operation 
than

stage-user
--from-delete, it just uses different container.

NACK on stuffing everything into a single command just
because it
does
something similar.
How about making it a 'stageuser-undel'? The 'user-undel' 
moves

preserved user to active, so the 'stageuser-undel' would move
preserved
to staged. The action is similar, but has slightly different
specifics
(which attributes are preserved etc.), and for me the
'stageuser-undel'
feels more natural than 'user-undel --to-staged' since it's
basically
the same as there is 'stageuser-add' for creating a staged
user, not
'user-add --to-staged'. It would be in the same style as 
all the

other
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 are
suggesting is not.

Also I'm not sure if we want to (always) remove the deleted
user once
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
arbitrary limitation.

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
'user'. So
I would vote for continuing with a 'user-*' commands and use
'user-undel
--to-stage'.

But then if we will make any incompatible change between
user-undel
and user-undel --to-stage we may hit this issue again. I
agree with
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 does.


That is a good point. Do we need to modify anything from a deleted
entry
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

Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-08-12 Thread Martin Basti



On 08/12/2015 02:08 PM, Tomas Capek wrote:

On 12/08/15 13:15, David Kupka wrote:

On 12/08/15 12:45, thierry bordaz wrote:

On 08/12/2015 12:35 PM, Martin Basti wrote:



On 08/11/2015 10:40 AM, thierry bordaz wrote:

On 08/11/2015 09:32 AM, Martin Basti wrote:

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:

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
Cc: freeipa-devel@redhat.com
Sent: Monday, August 3, 2015 5:34:02 PM
Subject: Re: [Freeipa-devel] Replace stageuser-add
--from-delete with
user-undel --to-staged

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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is
prompted to
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 huge
hack
in internal API. Or should we just document this bug as 
known

issue
(thierry wrote that this is not use case that should be 
used

often)?

The best solution would be separate command, but this idea
was
rejected in thread [Freeipa-devel] User life cycle: 
question

regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current
internal API
and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how
to fix
it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated

+1

* create new option for user-undel: used-undel 
--to-staged (or

create
new command) that will handle moving deleted users to 
staged

area as
--from-delete did.

Make it new command please.

Instead of stageuser-add and option --from-delete, which 
work

totally
different, the command user-undel does similar operation 
than

stage-user
--from-delete, it just uses different container.

NACK on stuffing everything into a single command just
because it
does
something similar.
How about making it a 'stageuser-undel'? The 'user-undel' 
moves

preserved user to active, so the 'stageuser-undel' would move
preserved
to staged. The action is similar, but has slightly different
specifics
(which attributes are preserved etc.), and for me the
'stageuser-undel'
feels more natural than 'user-undel --to-staged' since it's
basically
the same as there is 'stageuser-add' for creating a staged
user, not
'user-add --to-staged'. It would be in the same style as 
all the

other
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 are
suggesting is not.

Also I'm not sure if we want to (always) remove the deleted
user once
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
arbitrary limitation.

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
'user'. So
I would vote for continuing with a 'user-*' commands and use
'user-undel
--to-stage'.

But then if we will make any incompatible change between
user-undel
and user-undel --to-stage we may hit this issue again. I
agree with
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 does.


That is a good point. Do we need to modify anything from a deleted
entry
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

Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-08-12 Thread Tomas Capek

On 12/08/15 14:22, Martin Basti wrote:



On 08/12/2015 02:08 PM, Tomas Capek wrote:

On 12/08/15 13:15, David Kupka wrote:

On 12/08/15 12:45, thierry bordaz wrote:

On 08/12/2015 12:35 PM, Martin Basti wrote:



On 08/11/2015 10:40 AM, thierry bordaz wrote:

On 08/11/2015 09:32 AM, Martin Basti wrote:

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:

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
Cc: freeipa-devel@redhat.com
Sent: Monday, August 3, 2015 5:34:02 PM
Subject: Re: [Freeipa-devel] Replace stageuser-add
--from-delete with
user-undel --to-staged

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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is
prompted to
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 huge
hack
in internal API. Or should we just document this bug 
as known

issue
(thierry wrote that this is not use case that should 
be used

often)?

The best solution would be separate command, but this 
idea

was
rejected in thread [Freeipa-devel] User life cycle: 
question

regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current
internal API
and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way 
how

to fix
it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated

+1

* create new option for user-undel: used-undel 
--to-staged (or

create
new command) that will handle moving deleted users to 
staged

area as
--from-delete did.

Make it new command please.

Instead of stageuser-add and option --from-delete, 
which work

totally
different, the command user-undel does similar 
operation than

stage-user
--from-delete, it just uses different container.

NACK on stuffing everything into a single command just
because it
does
something similar.
How about making it a 'stageuser-undel'? The 'user-undel' 
moves
preserved user to active, so the 'stageuser-undel' would 
move

preserved
to staged. The action is similar, but has slightly different
specifics
(which attributes are preserved etc.), and for me the
'stageuser-undel'
feels more natural than 'user-undel --to-staged' since it's
basically
the same as there is 'stageuser-add' for creating a staged
user, not
'user-add --to-staged'. It would be in the same style as 
all the

other
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 are
suggesting is not.

Also I'm not sure if we want to (always) remove the deleted
user once
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

arbitrary limitation.

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
'user'. So
I would vote for continuing with a 'user-*' commands and use
'user-undel
--to-stage'.

But then if we will make any incompatible change between
user-undel
and user-undel --to-stage we may hit this issue again. I
agree with
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 does.

That is a good point. Do we need to modify anything from a 
deleted

entry
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

Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-08-11 Thread Jan Cholasta

On 5.8.2015 12:34, thierry bordaz wrote:

On 08/05/2015 12:13 PM, Jan Cholasta wrote:

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
Cc: freeipa-devel@redhat.com
Sent: Monday, August 3, 2015 5:34:02 PM
Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with
user-undel --to-staged

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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is
prompted to
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 huge
hack
in internal API. Or should we just document this bug as known
issue
(thierry wrote that this is not use case that should be used
often)?

The best solution would be separate command, but this idea was
rejected in thread [Freeipa-devel] User life cycle: question
regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current internal API
and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how to fix
it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated

+1


* create new option for user-undel: used-undel --to-staged  (or
create
new command) that will handle moving deleted users to staged
area as
--from-delete did.

Make it new command please.


Instead of stageuser-add and option --from-delete, which work
totally
different, the command user-undel does similar operation than
stage-user
--from-delete, it just uses different container.

NACK on stuffing everything into a single command just because it
does
something similar.

How about making it a 'stageuser-undel'? The 'user-undel' moves
preserved user to active, so the 'stageuser-undel' would move
preserved
to staged. The action is similar, but has slightly different
specifics
(which attributes are preserved etc.), and for me the
'stageuser-undel'
feels more natural than 'user-undel --to-staged' since it's basically
the same as there is 'stageuser-add' for creating a staged user, not
'user-add --to-staged'. It would be in the same style as all the
other
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 are
suggesting is not.

Also I'm not sure if we want to (always) remove the deleted user once
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
arbitrary limitation.

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 'user'. So
I would vote for continuing with a 'user-*' commands and use
'user-undel
--to-stage'.

But then if we will make any incompatible change between user-undel
and user-undel --to-stage we may hit this issue again. I agree with
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 does.


That is a good point. Do we need to modify anything from a deleted entry
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.


--
Jan Cholasta

Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-08-11 Thread thierry bordaz

On 08/11/2015 09:32 AM, Martin Basti wrote:

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:

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
Cc: freeipa-devel@redhat.com
Sent: Monday, August 3, 2015 5:34:02 PM
Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete 
with

user-undel --to-staged

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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is
prompted to
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 
huge

hack
in internal API. Or should we just document this bug as known
issue
(thierry wrote that this is not use case that should be used
often)?

The best solution would be separate command, but this idea was
rejected in thread [Freeipa-devel] User life cycle: question
regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current internal API
and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how 
to fix

it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated

+1


* create new option for user-undel: used-undel --to-staged  (or
create
new command) that will handle moving deleted users to staged
area as
--from-delete did.

Make it new command please.


Instead of stageuser-add and option --from-delete, which work
totally
different, the command user-undel does similar operation than
stage-user
--from-delete, it just uses different container.

NACK on stuffing everything into a single command just because it
does
something similar.

How about making it a 'stageuser-undel'? The 'user-undel' moves
preserved user to active, so the 'stageuser-undel' would move
preserved
to staged. The action is similar, but has slightly different
specifics
(which attributes are preserved etc.), and for me the
'stageuser-undel'
feels more natural than 'user-undel --to-staged' since it's 
basically
the same as there is 'stageuser-add' for creating a staged 
user, not

'user-add --to-staged'. It would be in the same style as all the
other
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 
are

suggesting is not.

Also I'm not sure if we want to (always) remove the deleted user 
once

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
arbitrary limitation.

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 
'user'. So

I would vote for continuing with a 'user-*' commands and use
'user-undel
--to-stage'.

But then if we will make any incompatible change between 
user-undel
and user-undel --to-stage we may hit this issue again. I agree 
with

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 
does.


That is a good point. Do we need to modify anything from a deleted 
entry

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

Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-08-11 Thread Martin Basti

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:

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
Cc: freeipa-devel@redhat.com
Sent: Monday, August 3, 2015 5:34:02 PM
Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with
user-undel --to-staged

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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is
prompted to
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 huge
hack
in internal API. Or should we just document this bug as known
issue
(thierry wrote that this is not use case that should be used
often)?

The best solution would be separate command, but this idea was
rejected in thread [Freeipa-devel] User life cycle: question
regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current internal API
and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how to 
fix

it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated

+1


* create new option for user-undel: used-undel --to-staged  (or
create
new command) that will handle moving deleted users to staged
area as
--from-delete did.

Make it new command please.


Instead of stageuser-add and option --from-delete, which work
totally
different, the command user-undel does similar operation than
stage-user
--from-delete, it just uses different container.

NACK on stuffing everything into a single command just because it
does
something similar.

How about making it a 'stageuser-undel'? The 'user-undel' moves
preserved user to active, so the 'stageuser-undel' would move
preserved
to staged. The action is similar, but has slightly different
specifics
(which attributes are preserved etc.), and for me the
'stageuser-undel'
feels more natural than 'user-undel --to-staged' since it's 
basically
the same as there is 'stageuser-add' for creating a staged user, 
not

'user-add --to-staged'. It would be in the same style as all the
other
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 are
suggesting is not.

Also I'm not sure if we want to (always) remove the deleted user 
once

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
arbitrary limitation.

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 
'user'. So

I would vote for continuing with a 'user-*' commands and use
'user-undel
--to-stage'.

But then if we will make any incompatible change between user-undel
and user-undel --to-stage we may hit this issue again. I agree with
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 
does.



That is a good point. Do we need to modify anything from a deleted entry
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

Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-08-05 Thread Martin Basti


- Original Message -
From: thierry bordaz tbor...@redhat.com
To: Jan Cholasta jchol...@redhat.com
Cc: freeipa-devel@redhat.com
Sent: Monday, August 3, 2015 5:34:02 PM
Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with 
user-undel --to-staged

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:
 Hello,

 I tried to fix #5145 and I partially succeeded.

 However, I cannot fix this part of ticket, where user is prompted to
 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 huge hack
 in internal API. Or should we just document this bug as known issue
 (thierry wrote that this is not use case that should be used often)?

 The best solution would be separate command, but this idea was
 rejected in thread [Freeipa-devel] User life cycle: question
 regarding the design

 Regards
 Martin^2

 Hello,

 as was mentioned before, we have issue with current internal API 
 and the
 stageuser-add --from-delete command.

 We discussed this today, and we did not find a nice way how to fix it,
 so we propose this (which is IMO the best solution):

 * stageuser-add --from-delete should be deprecated

 +1

 * create new option for user-undel: used-undel --to-staged  (or create
 new command) that will handle moving deleted users to staged area as
 --from-delete did.

 Make it new command please.


 Instead of stageuser-add and option --from-delete, which work totally
 different, the command user-undel does similar operation than 
 stage-user
 --from-delete, it just uses different container.

 NACK on stuffing everything into a single command just because it does
 something similar.

 How about making it a 'stageuser-undel'? The 'user-undel' moves
 preserved user to active, so the 'stageuser-undel' would move preserved
 to staged. The action is similar, but has slightly different specifics
 (which attributes are preserved etc.), and for me the 'stageuser-undel'
 feels more natural than 'user-undel --to-staged' since it's basically
 the same as there is 'stageuser-add' for creating a staged user, not
 'user-add --to-staged'. It would be in the same style as all the other
 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 are 
 suggesting is not.

 Also I'm not sure if we want to (always) remove the deleted user once 
 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 
 arbitrary limitation.

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 'user'. So 
I would vote for continuing with a 'user-*' commands and use 'user-undel 
--to-stage'.

But then if we will make any incompatible change between user-undel and 
user-undel --to-stage we may hit this issue again. I agree with Honza, this 
should be a separate command.

Martin2


 I think that what we are looking for is the opposite of 
 stageuser-activate. So maybe user-stage?


-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-08-05 Thread thierry bordaz

On 08/05/2015 11:27 AM, Martin Basti wrote:


- Original Message -
From: thierry bordaz tbor...@redhat.com
To: Jan Cholasta jchol...@redhat.com
Cc: freeipa-devel@redhat.com
Sent: Monday, August 3, 2015 5:34:02 PM
Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with 
user-undel --to-staged

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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is prompted to
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 huge hack
in internal API. Or should we just document this bug as known issue
(thierry wrote that this is not use case that should be used often)?

The best solution would be separate command, but this idea was
rejected in thread [Freeipa-devel] User life cycle: question
regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current internal API
and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how to fix it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated

+1


* create new option for user-undel: used-undel --to-staged  (or create
new command) that will handle moving deleted users to staged area as
--from-delete did.

Make it new command please.


Instead of stageuser-add and option --from-delete, which work totally
different, the command user-undel does similar operation than
stage-user
--from-delete, it just uses different container.

NACK on stuffing everything into a single command just because it does
something similar.

How about making it a 'stageuser-undel'? The 'user-undel' moves
preserved user to active, so the 'stageuser-undel' would move preserved
to staged. The action is similar, but has slightly different specifics
(which attributes are preserved etc.), and for me the 'stageuser-undel'
feels more natural than 'user-undel --to-staged' since it's basically
the same as there is 'stageuser-add' for creating a staged user, not
'user-add --to-staged'. It would be in the same style as all the other
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 are
suggesting is not.

Also I'm not sure if we want to (always) remove the deleted user once
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
arbitrary limitation.

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 'user'. So
I would vote for continuing with a 'user-*' commands and use 'user-undel
--to-stage'.

But then if we will make any incompatible change between user-undel and 
user-undel --to-stage we may hit this issue again. I agree with 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 ?


thanks
thierry

Martin2


I think that what we are looking for is the opposite of
stageuser-activate. So maybe user-stage?




--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-08-05 Thread Jan Cholasta

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
Cc: freeipa-devel@redhat.com
Sent: Monday, August 3, 2015 5:34:02 PM
Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with
user-undel --to-staged

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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is prompted to
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 huge
hack
in internal API. Or should we just document this bug as known issue
(thierry wrote that this is not use case that should be used often)?

The best solution would be separate command, but this idea was
rejected in thread [Freeipa-devel] User life cycle: question
regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current internal API
and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how to fix
it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated

+1


* create new option for user-undel: used-undel --to-staged  (or
create
new command) that will handle moving deleted users to staged area as
--from-delete did.

Make it new command please.


Instead of stageuser-add and option --from-delete, which work totally
different, the command user-undel does similar operation than
stage-user
--from-delete, it just uses different container.

NACK on stuffing everything into a single command just because it does
something similar.

How about making it a 'stageuser-undel'? The 'user-undel' moves
preserved user to active, so the 'stageuser-undel' would move preserved
to staged. The action is similar, but has slightly different specifics
(which attributes are preserved etc.), and for me the 'stageuser-undel'
feels more natural than 'user-undel --to-staged' since it's basically
the same as there is 'stageuser-add' for creating a staged user, not
'user-add --to-staged'. It would be in the same style as all the other
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 are
suggesting is not.

Also I'm not sure if we want to (always) remove the deleted user once
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
arbitrary limitation.

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 'user'. So
I would vote for continuing with a 'user-*' commands and use 'user-undel
--to-stage'.

But then if we will make any incompatible change between user-undel
and user-undel --to-stage we may hit this issue again. I agree with
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 does.


--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-08-05 Thread thierry bordaz

On 08/05/2015 12:13 PM, Jan Cholasta wrote:

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
Cc: freeipa-devel@redhat.com
Sent: Monday, August 3, 2015 5:34:02 PM
Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with
user-undel --to-staged

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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is 
prompted to

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 huge
hack
in internal API. Or should we just document this bug as known 
issue
(thierry wrote that this is not use case that should be used 
often)?


The best solution would be separate command, but this idea was
rejected in thread [Freeipa-devel] User life cycle: question
regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current internal API
and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how to fix
it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated

+1


* create new option for user-undel: used-undel --to-staged  (or
create
new command) that will handle moving deleted users to staged 
area as

--from-delete did.

Make it new command please.

Instead of stageuser-add and option --from-delete, which work 
totally

different, the command user-undel does similar operation than
stage-user
--from-delete, it just uses different container.
NACK on stuffing everything into a single command just because it 
does

something similar.

How about making it a 'stageuser-undel'? The 'user-undel' moves
preserved user to active, so the 'stageuser-undel' would move 
preserved
to staged. The action is similar, but has slightly different 
specifics
(which attributes are preserved etc.), and for me the 
'stageuser-undel'

feels more natural than 'user-undel --to-staged' since it's basically
the same as there is 'stageuser-add' for creating a staged user, not
'user-add --to-staged'. It would be in the same style as all the 
other

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 are
suggesting is not.

Also I'm not sure if we want to (always) remove the deleted user once
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
arbitrary limitation.

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 'user'. So
I would vote for continuing with a 'user-*' commands and use 
'user-undel

--to-stage'.

But then if we will make any incompatible change between user-undel
and user-undel --to-stage we may hit this issue again. I agree with
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 does.


That is a good point. Do we need to modify anything from a deleted entry 
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.



-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-08-03 Thread thierry bordaz

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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is prompted to
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 huge hack
in internal API. Or should we just document this bug as known issue
(thierry wrote that this is not use case that should be used often)?

The best solution would be separate command, but this idea was
rejected in thread [Freeipa-devel] User life cycle: question
regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current internal API 
and the

stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how to fix it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated


+1


* create new option for user-undel: used-undel --to-staged  (or create
new command) that will handle moving deleted users to staged area as
--from-delete did.


Make it new command please.



Instead of stageuser-add and option --from-delete, which work totally
different, the command user-undel does similar operation than 
stage-user

--from-delete, it just uses different container.


NACK on stuffing everything into a single command just because it does
something similar.


How about making it a 'stageuser-undel'? The 'user-undel' moves
preserved user to active, so the 'stageuser-undel' would move preserved
to staged. The action is similar, but has slightly different specifics
(which attributes are preserved etc.), and for me the 'stageuser-undel'
feels more natural than 'user-undel --to-staged' since it's basically
the same as there is 'stageuser-add' for creating a staged user, not
'user-add --to-staged'. It would be in the same style as all the other
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 are 
suggesting is not.


Also I'm not sure if we want to (always) remove the deleted user once 
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 
arbitrary limitation.


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 'user'. So 
I would vote for continuing with a 'user-*' commands and use 'user-undel 
--to-stage'.




I think that what we are looking for is the opposite of 
stageuser-activate. So maybe user-stage?



--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-07-28 Thread Jan Cholasta

Dne 27.7.2015 v 17:59 Martin Basti napsal(a):

On 23/07/15 14:43, Martin Basti wrote:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is prompted to
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 huge hack
in internal API. Or should we just document this bug as known issue
(thierry wrote that this is not use case that should be used often)?

The best solution would be separate command, but this idea was
rejected in thread [Freeipa-devel] User life cycle: question
regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current internal API and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how to fix it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated


+1


* create new option for user-undel: used-undel --to-staged  (or create
new command) that will handle moving deleted users to staged area as
--from-delete did.


Make it new command please.



Instead of stageuser-add and option --from-delete, which work totally
different, the command user-undel does similar operation than stage-user
--from-delete, it just uses different container.


NACK on stuffing everything into a single command just because it does 
something similar.




We need to do this in 4.2.1 to affect as least as possible users.

If you have any objections, please speak/write :)
Martin^2


--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-07-28 Thread Lenka Doudova



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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is prompted to
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 huge hack
in internal API. Or should we just document this bug as known issue
(thierry wrote that this is not use case that should be used often)?

The best solution would be separate command, but this idea was
rejected in thread [Freeipa-devel] User life cycle: question
regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current internal API and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how to fix it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated


+1


* create new option for user-undel: used-undel --to-staged  (or create
new command) that will handle moving deleted users to staged area as
--from-delete did.


Make it new command please.



Instead of stageuser-add and option --from-delete, which work totally
different, the command user-undel does similar operation than stage-user
--from-delete, it just uses different container.


NACK on stuffing everything into a single command just because it does 
something similar.


How about making it a 'stageuser-undel'? The 'user-undel' moves 
preserved user to active, so the 'stageuser-undel' would move preserved 
to staged. The action is similar, but has slightly different specifics 
(which attributes are preserved etc.), and for me the 'stageuser-undel' 
feels more natural than 'user-undel --to-staged' since it's basically 
the same as there is 'stageuser-add' for creating a staged user, not 
'user-add --to-staged'. It would be in the same style as all the other 
commands concerning operations with users in staged container.


Lenka





We need to do this in 4.2.1 to affect as least as possible users.

If you have any objections, please speak/write :)
Martin^2




--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-07-28 Thread Jan Cholasta

Dne 28.7.2015 v 16:54 Martin Basti napsal(a):

On 28/07/15 12:34, 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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is prompted to
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 huge hack
in internal API. Or should we just document this bug as known issue
(thierry wrote that this is not use case that should be used often)?

The best solution would be separate command, but this idea was
rejected in thread [Freeipa-devel] User life cycle: question
regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current internal API
and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how to fix it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated


+1


* create new option for user-undel: used-undel --to-staged  (or create
new command) that will handle moving deleted users to staged area as
--from-delete did.


Make it new command please.



Instead of stageuser-add and option --from-delete, which work totally
different, the command user-undel does similar operation than
stage-user
--from-delete, it just uses different container.


NACK on stuffing everything into a single command just because it does
something similar.


How about making it a 'stageuser-undel'? The 'user-undel' moves
preserved user to active, so the 'stageuser-undel' would move preserved
to staged. The action is similar, but has slightly different specifics
(which attributes are preserved etc.), and for me the 'stageuser-undel'
feels more natural than 'user-undel --to-staged' since it's basically
the same as there is 'stageuser-add' for creating a staged user, not
'user-add --to-staged'. It would be in the same style as all the other
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 are
suggesting is not.

Also I'm not sure if we want to (always) remove the deleted user once
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
arbitrary limitation.

I think that what we are looking for is the opposite of
stageuser-activate. So maybe user-stage?



Can we use stageuser-from-deleted ?



from-deleted is not a verb and like I said, restricting the command to 
deleted users only is rather arbitrary.


--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-07-28 Thread Petr Vobornik

On 07/28/2015 04:54 PM, Martin Basti wrote:

On 28/07/15 12:34, 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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is prompted to
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 huge hack
in internal API. Or should we just document this bug as known issue
(thierry wrote that this is not use case that should be used often)?

The best solution would be separate command, but this idea was
rejected in thread [Freeipa-devel] User life cycle: question
regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current internal API
and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how to fix it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated


+1


* create new option for user-undel: used-undel --to-staged  (or create
new command) that will handle moving deleted users to staged area as
--from-delete did.


Make it new command please.



Instead of stageuser-add and option --from-delete, which work totally
different, the command user-undel does similar operation than
stage-user
--from-delete, it just uses different container.


NACK on stuffing everything into a single command just because it does
something similar.


How about making it a 'stageuser-undel'? The 'user-undel' moves
preserved user to active, so the 'stageuser-undel' would move preserved
to staged. The action is similar, but has slightly different specifics
(which attributes are preserved etc.), and for me the 'stageuser-undel'
feels more natural than 'user-undel --to-staged' since it's basically
the same as there is 'stageuser-add' for creating a staged user, not
'user-add --to-staged'. It would be in the same style as all the other
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 are
suggesting is not.

Also I'm not sure if we want to (always) remove the deleted user once
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
arbitrary limitation.

I think that what we are looking for is the opposite of
stageuser-activate. So maybe user-stage?



Can we use stageuser-from-deleted ?



user-stage sounds better to me than stageuser-from-deleted

--
Petr Vobornik

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-07-28 Thread Jan Cholasta

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:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is prompted to
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 huge hack
in internal API. Or should we just document this bug as known issue
(thierry wrote that this is not use case that should be used often)?

The best solution would be separate command, but this idea was
rejected in thread [Freeipa-devel] User life cycle: question
regarding the design

Regards
Martin^2


Hello,

as was mentioned before, we have issue with current internal API and the
stageuser-add --from-delete command.

We discussed this today, and we did not find a nice way how to fix it,
so we propose this (which is IMO the best solution):

* stageuser-add --from-delete should be deprecated


+1


* create new option for user-undel: used-undel --to-staged  (or create
new command) that will handle moving deleted users to staged area as
--from-delete did.


Make it new command please.



Instead of stageuser-add and option --from-delete, which work totally
different, the command user-undel does similar operation than stage-user
--from-delete, it just uses different container.


NACK on stuffing everything into a single command just because it does
something similar.


How about making it a 'stageuser-undel'? The 'user-undel' moves
preserved user to active, so the 'stageuser-undel' would move preserved
to staged. The action is similar, but has slightly different specifics
(which attributes are preserved etc.), and for me the 'stageuser-undel'
feels more natural than 'user-undel --to-staged' since it's basically
the same as there is 'stageuser-add' for creating a staged user, not
'user-add --to-staged'. It would be in the same style as all the other
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 are suggesting 
is not.


Also I'm not sure if we want to (always) remove the deleted user once 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 arbitrary 
limitation.


I think that what we are looking for is the opposite of 
stageuser-activate. So maybe user-stage?


--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged

2015-07-27 Thread Martin Basti

On 23/07/15 14:43, Martin Basti wrote:

Hello,

I tried to fix #5145 and I partially succeeded.

However, I cannot fix this part of ticket, where user is prompted to 
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 huge hack 
in internal API. Or should we just document this bug as known issue 
(thierry wrote that this is not use case that should be used often)?


The best solution would be separate command, but this idea was 
rejected in thread [Freeipa-devel] User life cycle: question 
regarding the design


Regards
Martin^2


Hello,

as was mentioned before, we have issue with current internal API and the 
stageuser-add --from-delete command.


We discussed this today, and we did not find a nice way how to fix it, 
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 create 
new command) that will handle moving deleted users to staged area as 
--from-delete did.


Instead of stageuser-add and option --from-delete, which work totally 
different, the command user-undel does similar operation than stage-user 
--from-delete, it just uses different container.


We need to do this in 4.2.1 to affect as least as possible users.

If you have any objections, please speak/write :)
Martin^2

--
Martin Basti

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code