Optional username for email/password auth

[jimafisk]

If I use the Email/Password auth method for a collection, it still requires username as a system field. Our app doesn't use username in any way so it's extra information that we have set values for and think about during a user migration that we're running.

The inverse is also true, if I use an auth method of Username/Password, email is still a required system field.

It would be great if the only required fields were the ones used in the selected auth method. If you wanted an app with both username and email, you could set both Email/Password and Username/Password methods for that collection.

I assume both of these fields are required for PocketBase internals in some way? Thank you!

[ganigeorgiev]

There are plans in the future to change the system username field to a regular unique text field that users will be able to control (eg. specify their own min/max length and pattern or just remove it if they don't need it). The general idea is from the collection settings to allow user to choose the unique fields they want to use as identity for the password auth.

The email field on the other hand is a little more complicated and cannot be easily removed from the collection because other app components may depend on it even if the app doesn't have email/pass auth enabled (eg. transactional emails, OAuth2 linking, etc.).

But still I haven't thought much on it yet, it is just a note in my never ending todo, so the above may change once I start working on it. Eventually it will be handled together with the email change flow refactoring but there are no ETAs yet. I'll try to publish some more details in the near future, but as of now the current priorities (alongside Presentator) are:

• finish the ongoing auto backup and restore apis and tests
• selfupdate cli command (and maybe UI) for easier application upgrades when using the prebuilt executable
• prepare a testbed and some benchmarks so that we have something to compare to before the planned hooks refactoring and goja app hooks integration
• refactor the hooks and some of the related internals
• add support for goja hooks and dynamic code loading
• rewrite the docs

[jimafisk]

Thanks for the details @ganigeorgiev! I know you have a ton on your plate, so just want to note:

1. This is not a blocker for us, we can set default usernames for now
2. Our actual use-case is to remove username, the harder removal of emails was only theoretical (thought other folks might run into it though)