<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 05/22/2014 07:21 PM, Simo Sorce wrote: </div> <blockquote cite="mid:1400779286.7561.93.camel@willson.li.ssimo.org" type="cite"> <pre wrap="">On Thu, 2014-05-22 at 17:52 +0200, thierry bordaz wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/22/2014 04:38 PM, Martin Kosek wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/22/2014 10:47 AM, Petr Viktorin wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/21/2014 10:00 PM, Dmitri Pal wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/19/2014 10:45 AM, thierry bordaz wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/19/2014 04:44 PM, Jan Cholasta wrote: </pre> <blockquote type="cite"> <pre wrap="">On 19.5.2014 16:34, thierry bordaz wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/19/2014 04:22 PM, Jan Cholasta wrote: </pre> <blockquote type="cite"> <pre wrap="">On 19.5.2014 16:03, thierry bordaz wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/19/2014 03:54 PM, Jan Cholasta wrote: </pre> <blockquote type="cite"> <pre wrap="">On 19.5.2014 15:19, Petr Viktorin wrote: </pre> <blockquote type="cite"> <pre wrap="">Hello list, Here's a conversation that started internally. I'm making it public. On 05/19/2014 01:00 PM, Martin Kosek wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/19/2014 12:46 PM, Petr Viktorin wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/19/2014 08:25 AM, Martin Kosek wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/19/2014 08:24 AM, Martin Kosek wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/16/2014 04:48 PM, thierry bordaz wrote: </pre> <blockquote type="cite"> <pre wrap="">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 :-) </pre> </blockquote> <pre wrap="">Great! :-) </pre> <blockquote type="cite"> <pre wrap=""> 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 </pre> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> <pre wrap="">Note, the design is here: <a class="moz-txt-link-freetext" href="http://www.freeipa.org/page/V4/User_Life-Cycle_Management">http://www.freeipa.org/page/V4/User_Life-Cycle_Management</a> </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap=""> 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 </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> </blockquote> <pre wrap="">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@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 </pre> </blockquote> </blockquote> </blockquote> <pre wrap="">+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 </pre> </blockquote> <pre wrap="">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 ? </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">Ok I understand. I believe that deleted entries and staged entries will be in the same container (provisioning). </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">Oppsss.. Sorry for the confusion :-[ </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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 </pre> </blockquote> </blockquote> </blockquote> <pre wrap=""> 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 </pre> </blockquote> <pre wrap="">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: <a class="moz-txt-link-freetext" href="http://assets.osteele.com/images/2008/git-transport.png">http://assets.osteele.com/images/2008/git-transport.png</a> . 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? </pre> </blockquote> <pre wrap="">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 <a class="moz-txt-link-abbreviated" href="mailto:Freeipa-devel@redhat.com">Freeipa-devel@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-devel">https://www.redhat.com/mailman/listinfo/freeipa-devel</a> </pre> </blockquote> <pre wrap="">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. 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 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>) 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 </pre> </blockquote> <pre wrap=""> Do we ever want to allow to move a user from active to staging ? I can't find a case where my answer is yes. >From my POV a user once it leaves staging is either active or deleted, in my mind there is no reason ever to move a user into staging. In what case does it make sense ? Simo. </pre> </blockquote> Hi Simo, When moving an entry 'staging' -> 'active', some attributes are set (at least uidNumber,gidNumber, ipaUniqueId). In my mind, those attributes are set for ever even if later the entry is moved 'active'->'deleted'. One can imagine that an administrator is not "happy" with the values computed. For example, he would prefer uidNumber to be computed from an other range. For that, moving back the entry from 'active' -> 'staging' would be an option (if those attributes are 'reset'). I do not know if it is a valid use case but IMHO I would prefere he moves the entry 'active'->'delete' then delete the entry and recreate a new one. regards thierry </body> </html>