Skip to content

[Feature Request] don't require Full Name during email registration #532

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
tlubz opened this issue Jan 19, 2017 · 3 comments
Closed

[Feature Request] don't require Full Name during email registration #532

tlubz opened this issue Jan 19, 2017 · 3 comments

Comments

@tlubz
Copy link

tlubz commented Jan 19, 2017

I've looked around quite a bit, and from what I understand, the "Full Name" field on the email registration screen maps to displayName on the users collection. We want to skip collection of this field, or at least defer it until after the user is created. It seems like (though I'm not 100% certain, the docs are stingy on this) this field can be safely omitted from a user object, and we do not plan on using it in our apps directly.

What I'd like to see is a configuration option to skip collection of this field. The closest I can get right now is to simply hide that field by overriding the layout xml, which is hacky anyway, but that doesn't even really fix the problem that it is getting validated for presence by the UI in the email registration activity.

As of now, this field being required is a blocker. We would have to fork the repo or implement auth UI from scratch in order to get around this.

If there is a temporary work-around we can use, let me know.

Also I'm relatively new to firebase auth, so please let me know if I'm mistaken about any of this, or if you need more information.

@samtstern
Copy link
Contributor

@tlubz as you said, you can safely omit this field from the Firebase Auth user object. I think this would be a good feature to add, the main concern with this and other enable/disable flags is how to expose them without adding an explosion of complexity/configuration to this library.

@samtstern
Copy link
Contributor

Since this is already tracked in #467 I am going to close this issue and we can continue to discuss there if you have more thoughts on the topic.

@tlubz
Copy link
Author

tlubz commented Jan 19, 2017

@samtstern thanks for the quick response, and for pointing me to #476. for some reason it didn't pop up for the issue search terms i was using.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants