devise_invitable
devise_invitable copied to clipboard
scambra
Separate Invitations table instead of adding more columns to Users
It would probably be a good idea to separate the invitations into it's own table instead of adding more columns to the User table.
Yes. However, my request is less of "feature request" and more of a "let's extract this so we aren't polluting the User model."
More of a design decision change than a "I want this implemented for a new feature."
What's the affect right now if we run
$ rails generate devise_invitable invitees
and pick a table which is not our devise user table?
I mean what breaks? Would it help to say make this table inherit from users?
I agree with comments above that reflect that we are adding a lot of additional logic to User which seems can be encapsulated in the concept of invite or invitee.
I agree with the sentiments above. If someone chooses not to accept an invitation I'm ok with the invitation record lying around but I'd prefer to not have an extra, unused, user.
Any workarounds anyone can suggest would be appreciated.
Anyone have any luck putting invitable columns in their own table? We're thinking about adopting but want to avoid having non-active users in our users table.
Really in need of this functionality as well so that multiple invitations can exist. If no one has started working on it, maybe I can give some help on it
Anyone started work on this? I think this is a real problem with devise_invitable - it's not clear that having fields on the initial User table is ever better. You already have to do so many hacks out of the gate just to deal with uniqueness constraints on the user.
I've been working on it. I've had to make pretty substantial changes, though.... I'll be submitting it as a pull request and we can go from there.
@tminard any news? Just realized that sending an invite to someone effectively prevents them from being able to make a user account on their own, which is awful.
https://github.com/scambra/devise_invitable/blob/master/app/controllers/devise_invitable/registrations_controller.rb
RegistrationsController is overrided so registering with an invited email should work, there are some tests for that.
@tminard any updates on this? Would anyone be interested in pairing on this at some point?
Using a separate model and table for the invited users solves a few problems:
- Encapsulation of invite logic.
- Fewer columns on core
userstable. - There are no 'unused' users left lying around after invites go unaccepted.
- Multiple invitations can be sent to the same email (without overwriting previous invites)
- No need to override RegistrationsController to handle "registering with an invited email" case.
That said, the potential downside of this change is that invited users don't show up as actual users, even if you want them to. There are plenty of applications where being able to invite someone and then immediately treat them like any other user is really important. (Sort of like a placeholder until they actually sign up and take control.)
With that in mind, I would propose a "best of both worlds" approach, where by default invites do NOT create a user and go into their own 'user_invites' table, BUT using a simple configuration parameter, it should be possible to automatically generate a new user account, associated with the invite, but without all of the same overhead as the single-table approach.
Of course, the RegistrationsController override would have to be in place again to handle the "registering with an invited email" case, but other than that this seems to address all of the concerns -- by default you don't have any 'unused' users until the invitations get accepted, but depending on your application, you can decide to start creating those placeholder users, without needing to rework the way the invite system is set up.
It sounds like this would require rearchitecting a lot of the way devise_invitable currently works, so maybe this would be better suited for a different gem?
Advocating for this again - the way devise_invitable saves without validation is subtly breaking parts of my app over and over again - anytime you use a before_validation to ensure correctness of a model is out the window once devise_invitable is involved. That applies to nested validations, too. It's pretty bad!
For any of you that stumbled across this (like me) and were seeking a relatively abstracted gem - I've now had success with this gem https://github.com/tomichj/invitation
