On 19.5.2014 16:34, thierry bordaz wrote:
On 05/19/2014 04:22 PM, Jan Cholasta wrote:
On 19.5.2014 16:03, thierry bordaz wrote:
On 05/19/2014 03:54 PM, Jan Cholasta wrote:
On 19.5.2014 15:19, Petr Viktorin wrote:
Hello list,
Here's a conversation that started internally. I'm making it public.
On 05/19/2014 01:00 PM, Martin Kosek wrote:
On 05/19/2014 12:46 PM, Petr Viktorin wrote:
On 05/19/2014 08:25 AM, Martin Kosek wrote:
On 05/19/2014 08:24 AM, Martin Kosek wrote:
On 05/16/2014 04:48 PM, thierry bordaz wrote:
Hello Martin,
I am getting familiar with the freeipa CLI code and started
implemented '--to-stage' and '--from-stage'. This really an
impressive set of code :-)
Great! :-)
I completed 'to-stage' and testing '--from-stage'.
I have a question regarding the '--from-stage' syntax. 'uid'
is a
mandatory argument to 'user-add' subcommand. In the
design the
'--from-stage' option is described with:
ipa user-add --from-stage=tuser
Note, the design is here:
http://www.freeipa.org/page/V4/User_Life-Cycle_Management
But as 'uid' is mandatory the command should rather be
ipa user-add tuser --from-stage=tuser
In that case the option value for '--from-stage' is not
required and
the command should be
ipa user-add tuser --from-stage
Is that ok if I implement the command like above or did I
miss
something ?
regards
thierry
Hmm, no, I think you are right. We can change --from-stage to
just
Bool
parameter. When it is true, it'd mean that get_dn or pre-callback
should
retrieve the record from stage and use all it's attributes (and
add
standard
default attributes values on top of that).
Also CC-ing Petr Viktorin for reference.
This operation can't change the user's attributes, can it? I.e., we
don't
support something like:
ipa user-add tuser --from-stage --phone=123456789
--email=newem...@example.com
If this is the case, what's the reason for using user-add for this?
Wouldn't it
be better to make this a separate command, say:
ipa user-activate tuser
ipa user-activate tuser --from-deleted
ipa user-activate tuser --from-deleted --to-staged
+1, I would even go as far as having separate commands for staged and
deleted users, e.g.:
ipa user-unstage tuser
ipa user-undelete tuser
ipa user-undelete tuser --to-staged
A deleted entry has already been active so it contains already set
attributes while the pure staged entries are "almost" empty boxes. But
from an administrator point of view, both staged/deleted entries are
inactive. What would be the advantages of two separated commands ?
You just said it yourself: activating/unstaging a user is quite
different from undeleting a user. Cramming multiple different
operations in a single command is bad design IMHO.
Ok I understand.
I believe that deleted entries and staged entries will be in the same
container (provisioning).
The design page mentions "cn=staged
users,cn=accounts,cn=provisioning,$SUFFIX" and "cn=deleted
users,cn=accounts,cn=provisioning,$SUFFIX", which are two different
containers.
So we may have at least those two possibilities:
* ipa user-activate tuser [--from-staging|--from-delete]
* ipa user-unstage tuser
ipa user-undelete tuser
user-add command does a lot of additional processing besides just
taking the
values and writing them to LDAP. It fills the UID and GID, sets the
non-filled
default attributes like Kerberos attributes, adds user as a member of
ipausers
groups - all that stuff. The same procedures should be also done with
the user
from stage. This is why I proposed to augment user-add.
If there is a better way, I am open to it.
That's not a very good reason to bring in all the CLI/API options,
most
importantly from the user's perspective. Also you'd have to write
extra
code to e.g. check the user didn't use the other options, and that
tends
to get messy quite fast.
The common processing should be split out into functions* that both
commands would call.
(Or methods of the `user` object, which may turn out to be more
practical.)
--
Jan Cholasta
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
