Wordpress-ios: Signup username changer issues

Created on 9 Mar 2018  路  9Comments  路  Source: wordpress-mobile/WordPress-iOS

Expected behavior

  1. Re-selecting the default username should use it.
  2. Re-displaying the username changer should auto-select the current username, not the default one.

Actual behavior

When a username is selected other than the default, then returning to the username changer:

  1. Selecting the default username does not change it on the epilogue view. Since it doesn't change, the username ends up being the previously selected one.
  2. The default username is still auto-selected. I would expect the current username to be auto-selected instead.

Steps to reproduce the behavior

  • Create an account.
  • On the epilogue, select the username to bring up the username changer.
  • Select a username other than the default.
  • Return to the epilogue. The username is now the one selected.
    selected_from_suggestions

  • Select the username again.

  • Notice the default username is checked, and is shown as the current username in the top description.
    username_changer_redisplayed

  • Select the default username.

  • Return to the epilogue.
  • Notice the username did not change to the default.
  • Continue.
  • Notice the username is not the default, but is the one initially selected.
    account_username
NUX [Type] Bug

All 9 comments

@folletto - fixing this bug was rather simple. However, it presented another issue. When the username changer is launched, the suggestions are based on what the username _is_, not what it _was_. Therefore, if you select a username and return to the username changer, the default username is no longer shown in the list.

Ex:

  • When first reaching the epilogue, lets say the default username is 'scoutharris666'.
  • I select a different username in the changer, say 'imafool999'.
  • I go to the username changer again. This time the results are based off of 'imafool999'. Thus, 'scoutharris666' is no longer shown, and there is no way for the user to return to that username unless they manually do a search for it.

Questions:

  1. Is this acceptable?
  2. If not -
    2a. what do you see the solution being?
    2b. can we launch with the current behavior?

cc: @elibud

If you search for the original username can you still get it?

Is this acceptable?

Yes.

@elibud , @folletto -

If you search for the original username can you still get it?

Well, I thought so. I guess I was blind. I just tried again, and it turns out - No. 馃槥

Guess: it's because at creation it gets reserved, as such the API can't return it as available.

So: it would be nice if the client stores the old one, and keeps it always in the list, regardless of other choices (and simply doesn't do the API call if the user went back to it).

That said, I think it's not a major issue and we can ship without if needed.

@folletto -

it would be nice if the client stores the old one, and keeps it always in the list, regardless of other choices (and simply doesn't do the API call if the user went back to it).

Agreed. I'll create a new issue for that. Thanks!

cc: @elibud

@ScoutHarris at that point is the account already created? can we authenticate the suggestion call to get the original name?

Just to make a note - as @elibud and I discussed, fetching username suggestions is authenticated. We would expect the endpoint to return the reserved username when searched for. A p2 post will be made!

Fixed with #8867

Was this page helpful?
0 / 5 - 0 ratings