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

[thierry bordaz]

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 ?


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