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

[Petr Viktorin]

On 05/19/2014 03:19 PM, 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
>>
>> 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.)
>



On 05/19/2014 01:01 PM, thierry bordaz wrote:
> Hello Petr,
>
>     The command  moves an entry from staging to 'users'. When doing this there are the following added values:
>
>         objectClass: mepOriginEntry
>         mepManagedEntry: cn=titi,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,
>          dc=com
>
>
>     I guess it is the effect of a plugin because the command by itself just does a modrdn.
>     I agree with you, the design present this operation (staging-> 'users') as activating an account. It would make sense to use the 'user-activate' verb rather than 'user-add' as the entry is already added.
>
>     So if we want to modify an entry that is still in staging, would we need a '--to-stage' for the user-mod command ?

If the uids are unique we don't technically need it, but requiring it 
may still be a good idea, just to make sure the admin knows what they're 
doing.

Code-wise it'll definitely be easier to require the option, and it'll 
most likely also be a bit better for performance.


-- 
Petr³