[Freeipa-devel] Status/Question about User life cycle
thierry bordaz
tbordaz at redhat.com
Mon May 19 14:34:24 UTC 2014
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=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.
Ok I understand.
I believe that deleted entries and staged entries will be in the same
container (provisioning). 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.)
>>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140519/c06d2999/attachment.htm>
More information about the Freeipa-devel
mailing list