Developer must be signed in to create a profile about railsdevs.com

[stevepolitodesign]

@joemasilotti I recommend we enable devise :confirmable from the start to limit SPAM. What do you think?

[joemasilotti]

Definitely! Good call.

[caseyjenks]

@joemasilotti What are your thoughts on having a User model where all of the devise fields live, and then having Developer and Business(probably a better name for this class) subclasses which inherit from and belong_to User. Otherwise, we'll end up with 2 devise models in the app.

[fetijashari]

Since here we are talking different type of roles and user and maybe different subscriptions- I'd suggest we Implement User and Accounts. Simply said, this will enable the user to have different accounts (and within those accounts to have different teams that he can invite) / different subscriptions for those accounts. This will solve one part: Business Accounts as for developers - they will be just a normal users for begining.

What do you guys think ?

[joemasilotti]

I was hoping we wouldn't need accounts vs. users just yet, but it's always easier to build them now vs. later. So if someone throws together a PR with both built in, even at its simplest level (sign up, switching, etc.) I'm on board with that approach.

I also agree with Developer and Business (or other name) belonging to a User. But why would they also inherit from User? Can you explain that a little bit?

[nsoseka]

I think having one User model and then defining roles will fit perfectly for this scenario. Having 2 models looks a little bit like overkill for this. If the approach of using a single User model is good, I can run a PR for that.

Then again, I also think its best to setup all devise modules except omniauth in the migration file just incase we decide to use any for letter. We must not use it immediately but its good to have it now and as someone pointed above `confirmable is great to avoid spam.

Last question. Should I shoot this out with the free tailwindcss sign up?

[joemasilotti]

Ideally, I want to see Accounts / Users built at the same time. But if someone submits a PR that only does User authentication that's a fine place to start.

I strongly prefer to keep code we aren't using out of the codebase, even if we "might" use it in the future. So for the migration, only adding what will be used for the active PR.

As for design, feel free to use Tailwind UI if you have a license. Or leave it undesigned and someone else can style it later.

[Tonksthebear]

Ideally, I want to see Accounts / Users built at the same time. But if someone submits a PR that only does User authentication that's a fine place to start.

I strongly prefer to keep code we aren't using out of the codebase, even if we "might" use it in the future. So for the migration, only adding what will be used for the active PR.

As for design, feel free to use Tailwind UI if you have a license. Or leave it undesigned and someone else can style it later.

Whoa, TailwindUI can be used in an open source project? I assumed public code would break the license, but it definitely seems to imply you can use it in projects such as this...

Do you want to manage rolls in a column directly in the model, or use something like rolify?

[joemasilotti]

Yep!

You can:

Use the Components to create End Products that are open source and freely available to End Users.

[fetijashari]

Is anyone working on this ? @joemasilotti do you know ?

[joemasilotti]

Not that I'm aware of!

[joemasilotti]

I ended up pulling the trigger on this since it was blocking a few other issues/PRs.

The current implementation is a basic devise installation with a User model. Accounts and roles can come later.