@noodles: A long time ago, RnR started using SSO v2[0]. Prior to that, through the v1 SSO API, the LP username was *sometimes* available and it was used when it was. Since SSO v2 API account details doesn't really provide a possible username, for new reviewers the consumer_key is what's being used (as it's really the unique identifier for a particular username). This means that for *new* users (after the change!), the consumer_key would be the `User.username` (and hence the `reviewer_username` field value for the newer instances).
Later, at some point, the click reviews needed this inconsistency fixed and this branch was born[1]. In there we changed the `reviewer_username` field to always return the consumer_key (regardless of the `User.username`). My vote, for consistency and simplicity, is to go ahead and do exactly the same for deb reviews as suggested by @dobey.
@noodles: A long time ago, RnR started using SSO v2[0]. Prior to that, through the v1 SSO API, the LP username was *sometimes* available and it was used when it was. Since SSO v2 API account details doesn't really provide a possible username, for new reviewers the consumer_key is what's being used (as it's really the unique identifier for a particular username). This means that for *new* users (after the change!), the consumer_key would be the `User.username` (and hence the `reviewer_username` field value for the newer instances).
Later, at some point, the click reviews needed this inconsistency fixed and this branch was born[1]. In there we changed the `reviewer_username` field to always return the consumer_key (regardless of the `User.username`). My vote, for consistency and simplicity, is to go ahead and do exactly the same for deb reviews as suggested by @dobey.
[0] https:/ /code.launchpad .net/~fgallina/ rnr-server/ ssov2/+ merge/227058 /code.launchpad .net/~fgallina/ rnr-server/ click-reviews- return- useroid- as-username/ +merge/ 257106
[1] https:/