-
Notifications
You must be signed in to change notification settings - Fork 257
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
Developer must be signed in to create a profile #7
Comments
@joemasilotti I recommend we enable |
Definitely! Good call. |
@joemasilotti What are your thoughts on having a |
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 ? |
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? |
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? |
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? |
Yep!
|
Is anyone working on this ? @joemasilotti do you know ? |
Not that I'm aware of! |
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 |
Use devise for user authentication.
The text was updated successfully, but these errors were encountered: