<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 22/09/16 10:45, Steve Martinelli
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAHc_MXEQe=2p4iBZX9nk4eOrEB4ic=+Q799Te4FrhtVkHGWwvg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Wed, Sep 21, 2016 at 6:34 PM,
            Adrian Turjak <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:adriant@catalyst.net.nz" target="_blank">adriant@catalyst.net.nz</a>></span>
            wrote:<br>
            <br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"> - or update
                "openstack project list" with a "--auth-user" flag that
                ignores all other options and directly filters the
                project list by your token's user id. This type of
                option is already present in the "role assignment list"
                command. From a UX standpoint part of me feels that
                project list should default to --auth-user if your token
                doesn't have admin roles, but I'm not sure how easy that
                would be to do.<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>I prefer this one. The issue with defaulting to
              --auth-user (this was proposed at one point) is that it
              breaks the existing behaviour (listing all projects).</div>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Alright, will throw up a blueprint and get some code together for
    this soon.<br>
    <br>
    As for the defaulting, since the auth_ref does have your roles can't
    we just check if an admin (or admin like role) is present? The main
    problem I see here is the disconnect between actual policy and the
    chance of a deployment using other role names.<br>
    <br>
    Another option being that if a permissions error happens it could
    default to --auth-user, but that in turn might make some debugging
    harder.<br>
    <br>
    That's why my other suggestion was an entirely separate command,
    since there is no existing behavior to break and the default then
    feels the most sensible and clearer for someone trying to list their
    own projects. I mean, in keystone 'user project list' is a different
    api endpoint, it's only the keystone client which merges them into
    one command. ;)<br>
  </body>
</html>