On 05/22/2014 05:52 PM, 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.

I personally think that inactive state may be confusing. Is inactive deleted
user? Or staged user? Or active disabled user (user-disable command)? Inactive
state would have too many meanings. The previously proposed states active,
staging and deleted sounds clearer to me.

>    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

If by inactive you mean deleted, then yes.

> 
>    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>)

--inactive -> --deleted

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

Why is having ipaUniqueID attribute a problem for a staged user?

The command to "inactivate" the user is user-del.

> 
>    4) modify the user
> 
>        (from active)       ipa user-mod # (after the command
>        ipaUniqueID=<final value>)
>        (from inactive)     ipa user-mod   --inactive# (after the
>        command ipaUniqueID=<final value>)

--inactive -> --deleted

>        (from staging)      ipa user-mod --stage # (after the command
>        ipaUniqueID=generate)
> 
> 
>    5) delete user
> 
>        (staging to delete)   ipa user-del
>        (inactive to delete)  ipa user-del --inactive
> 
>        Here the entries are definitely removed

I would stick to original proposal:

(from active) ipa user-del tuser
(from stage)  ipa user-del tuser --staged

Martin

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

Reply via email to