post-review: User username/password arguments for login when provided

Review Request #713 — Created Jan. 21, 2009 and submitted

Information

Review Board SVN (deprecated)
762

Reviewers

The post-review script should use values provided in username/password argument when provided.
Currently it first looks for cookie and if valid cookie is found the username/password arguments are ignored. Hence if I need to use different login than one I use regularly, the cookie needs to be deleted.

With this change, username/password arguments are given higher priority than the session cookie.

 
chipx86
  1. 
      
  2. Can you use the same prompt format in the one below, with the "==>" ?
    
    Actually, it would be nice to just reuse the same prompt, and have the code for getting the password only happen once. Mainly just move the "if not password" toward the end. It should condense the code here nicely.
    1. I am not able to understand your comment about moving 'if not password' towards the end. Can you please explain it a bit? How can I retain the logic of using username/password when provided if I move the block.
    2. Actually, yeah, I don't have a good recommendation for that. Just have it print the "==> Review Board Login Required" before your "Enter password for ..." and it'll be good.
    3. Done.
      
      Sorry for multiple uploads of diff. My checkout was not updated. Please consider only diff revision 4.
  3. 
      
ON
ON
ON
Review request changed
chipx86
  1. Sorry for the delay on this. Been too busy to get to reviews lately.
    
    This is looking better, but it breaks submit_as. Shouldn't be a hard fix, but we need to make sure that username is set to options.submit_as if options.username is not provided and options.submit_as is.
    
    Probably can do something as simple as:
    
    username = options.username or options.submit_as
    
    We'd need this tested before it can go in though. Should be simple, just need a test user with the can_submit_as_user permission.
  2. 
      
david
  1. Thanks. I've just submitted a somewhat different fix for this bug (17bd345 in rbtools) that's a little more correct.
  2. 
      
Loading...