Is there a way to add new fields to `phx.gen.auth` easier?

Phoenix Forum Questions / Help
, ,
#1

Is there a way to add new fields to phx.gen.auth easier?

I added an username field and it works just fine, but it took quite a time and I had to update a lot of stuff for a simple username.

Also, there are like 110 tests that don’t include the new fields and I really don’t want to change them manually.

Is there an easier way to change them? Or should I just remove all of them and only add the ones that are really important?

Thanks!

#2

Do you mean 110 tests started failing or rather that 110 tests needed changing? If so, the question would be why the 110 tests would need to change. :slight_smile:

1 Like
#3

I mean, since the tests are only for the email and password fields, I think I have to update most of them, if not all of them.

And yeah, most of them are failing because of the changes I’ve made :slightly_smiling_face:

#4

Can’t advise you on how to change 110 existing tests but it’s a good opportunity to make test helper functions that assert on certain common structs and conditions and start replacing all hardcoded tests with using those helper functions. That way in the Future™ you would only change things in 2-3 places.

2 Likes
#5

Alright, I see.

Thanks!

#6

I did this recently and feel like I only updated a few tests (maybe five or six?). So long as email remains a key identifier of a Accounts.User, you shouldn’t need to go adding username everywhere you see email and password (or even just email) in the tests. So long as you have some tests asserting that a username is required, present, and unique, that should be enough coverage around it. Apart from that, you just need to update the fixture to ensure you don’t have to worry about adding a username for tests that aren’t concerned with it.

Of course, if you are going to allow users to login with their username instead of their password, that’s a different story. It still shouldn’t be that many test changes. You’d need to update any place that fetches by username/password, but once you have a loaded user, the rest of the functions that use email can stay the same.

Another route I’ve taken in a multi-tenant app is to leave the Accounts context completely alone. Once a user logs in with their email and password, they become an OrgMember in an Orgs context (for example) and choose a username post-registration. OrgMember can either be its own table or it could point to the users table (there are pros and cons to both ways). In either scenario, the only thing OrgMember schema needs to know from User is email. This way, way you have really clean separation between authorization and the rest of your app and you don’t have to futz about with generated code.

2 Likes
#7

Thanks for the answer! I guess I shouldn’t add username to everything that has email and password in it.

1 Like
#8

Update, I updated the fixture and some other tests and now I only have around 15 tests that fail :slightly_smiling_face:

Thanks for the help!

2 Likes
#9

Hello a asking , the way in

mix phx.gen.html Accounts Driver drivers name:string age:int status:string

Makes schema,html,and migration for Drivers

why can’t we do that again with auth.

What if we need to seriously authenticate those Drivers.

Do you know an easier way. I don want o make login and signups from scratch.

#10

Generating working code from nothing is easy, generating working code on top of existing code (like the Driver schema created by phx.gen.html) is massively harder.

You could try running phx.gen.auth in a brand-new Phoenix project and copy over the relevant bits of the output to your current project.

1 Like