[Freeipa-devel] Status/Question about User life cycle

[Jan Cholasta]

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=newemail at 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.

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