On 05/23/2014 05:03 PM, Simo Sorce wrote:
On Fri, 2014-05-23 at 10:07 +0200, thierry bordaz wrote:
On 05/22/2014 07:21 PM, Simo Sorce wrote:
On Thu, 2014-05-22 at 17:52 +0200, thierry bordaz wrote:
On 05/22/2014 04:38 PM, Martin Kosek wrote:
On 05/22/2014 10:47 AM, Petr Viktorin wrote:
On 05/21/2014 10:00 PM, Dmitri Pal wrote:
On 05/19/2014 10:45 AM, thierry bordaz wrote:
On 05/19/2014 04:44 PM, Jan Cholasta wrote:
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.
Oppsss.. Sorry for the confusion :-[
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
I like the idea of different verbs for different hives.
Something like:

Adding directly to stage via CLI: ipa user-stage
Removing from stage: user-unstage (user is gone)
Stage to Main -> activate; <- deactivate
Main to delete -> del; <-restore or undelete
Delete to stage -> I think we can use ipa user-stage command with
--deleted=user or similar
To be honest, I don't like this idea.
Too many names are confusing, if we can find a consistent option to cut the
number of names down we should do it.
IMO This is the worst part of Git:
http://assets.osteele.com/images/2008/git-transport.png . We can do better.

Another good thing would be if options did not affect the applicability of
other options (too much). For example in your proposal there'd be something 
like:
       ipa user-stage tuser --first=abc --last=xyz --phone=123 ......
       ipa user-stage --deleted=tuser  # <no attribute options allowed>
We should avoid this, if only for the reason that it makes the help text
confusing.


My proposal would be that the move commands use the verb for the target and an
option for the source, and add/mod use an option for the container:

1) adding a new user
(to active)   ipa user-add tuser ...
(to stage)    ipa user-add tuser --staged ...
(to deleted)  ipa user-add tuser --deleted ...  (*)

2) moving to main
(from stage)  ipa user-activate tuser  (**)
(from del)    ipa user-activate tuser --deleted

3) moving to deleted
(from active) ipa user-del tuser
(from stage)  ipa user-del tuser --staged

4) moving to stage
(from active) ipa user-stage tuser
(from del)    ipa user-stage tuser --deleted

5) modifying
(in active)   ipa user-mod tuser ...
(in stage)    ipa user-mod tuser --staged ...
(in del)      ipa user-mod tuser --deleted ...

Five commands (two of which are user-specific), plus two fairly consistent
options.

If the delete container isn't configured, the --deleted option is illegal and
`user-del` deletes permanently.


(*) may be useful in some situations?
I personally cannot imagine such situation - I would not add this command. If
somebody needs that, he can workaround with

ipa user-add tuser --staged
ipa user-del tuser --staged

... and report us the use case when it's needed. But I general, Petr's proposal
makes sense to me, I would go for it. (and update the design as Dmitri
correctly proposed).

Martin

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

      I will update the design following Petr proposal. Great one !
      However I was thinking to a sligthly different proposal.  For
      example if we have 3 states: staging, active, inactive.
      1) adding a user

          (...to active) ipa user-add# ( after the command
          ipaUniqueID=<final value>)
          (... to staging) ipa user-add --stage# (after the command
          ipaUniqueID=generate)

          So here we can not add a user directly into inactive state

      2) activating the user

          (staging to active)   ipa user-activate# (after the command
          ipaUniqueID=<final value>)
          (inactive to active)  ipa user-activate --inactive# (after the
          command ipaUniqueID=<final value>)

      3) inactivate the user

          (active to inactive)  ipa user-inactivate# (after the command
          ipaUniqueID=<final value>)

          Here there is no possibility to move back an active entry to
          staging, because in staging
          the entries do not have ipaUniqueID set
Do we ever want to allow to move a user from active to staging ?

I can't find a case where my answer is yes.

  From my POV a user once it leaves staging is either active or deleted,
in my mind there is no reason ever to move a user into staging.

In what case does it make sense ?

Simo.

Hi Simo,

When moving an entry 'staging' -> 'active', some attributes are set (at
least uidNumber,gidNumber, ipaUniqueId). In my mind, those attributes
are set for ever even if later the entry is moved 'active'->'deleted'.
One can imagine that an administrator is not "happy" with the values
computed. For example, he would prefer uidNumber to be computed from an
other range.
No, this is not in play. The reason we have been requested the 'deleted'
area is for regulatory purposes where the administrators are *mandated*
to keep users intact *especially* for uniquely identifying IDs.

Ok I agree.
Now I was thinking to an other reason an administrator would appreciate 'active' -> 'stage'. The move 'stage' -> 'active' requires an approval. Then the policy changes and some active users now needs an additional approval.
It would be a possibility to return the active user to the staging area.


For that, moving back the entry from 'active' -> 'staging' would be an
option (if those attributes are 'reset').
No, if the admins does not like uid numbers or unique ids, what it
really means is that the admin just wanted to delete the original user
and recreate a completely new one with the same name. In that case the
admin should do just that.

In the rare case when the admin really want to delete-and-preserve, and
later on change some uniquely identifying attributes he has already 2
ways:
1) 'un'delete the user and *then* change the ids, simple,
straightforward.
2) use ldamodify to change the entry while in the deleted area.

I do not know if it is a valid use case but IMHO I would prefere he
moves the entry 'active'->'delete' then delete the entry and recreate a
new one.
You can do it, see above.

I think the only operations allowed should be the following:

1. add user in staging area
2. un-stage user
3. move user to delete area
4. un-delete user
In all cases users in the staging or deleted area cannot be modified via
ipa commands

I do not think any other operation should be 'aided' by ipa tools unless
there is overwhelming request motivated by reasonable work-flows to do
anything else. If there is this request we can add more in the future.
Admins that need to change stuff can do so when the user is 'live', or
can use ldapmodify and directly access the entries in LDAP.

Simo.


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

Reply via email to