Rails4 - 设计 - 用户可以生成合作伙伴,合作伙伴是用户类

时间:2014-08-12 10:30:32

标签: ruby-on-rails ruby-on-rails-4 devise polymorphism

我使用的是rails 4和Devise身份验证。

用户注册只需要电子邮件,然后在电子邮件验证后,询问用户名,名字,姓氏和名片。要填写的密码。

用户拥有(拥有)团队,他可以在其中添加合作伙伴。

合作伙伴是用户类,因为它们具有相同的属性。

这是一个非常简单的逻辑,但由于Devise单独进行了大量操作,我想知道它是否应该遵循正确的方法,我的意思是为用户和合作伙伴共享用户模型而不是每个人都有专门的模型。

每个例子,我都记得这些事情:

  

我如何"自动激活"我的合作伙伴,意味着重写设计激活过程?

- >然后,合作伙伴会立即在应用内看到

- >合作伙伴不会被允许明显登录

后来的逻辑:

  

稍后,如果用户尝试注册并且他的电子邮件已存在于数据库中,则会:

- >检查用户状态

---->如果它是合作伙伴,那么会创建一个状态为" user"

的新帐户

---->如果是用户,则会通过电子邮件发送密码提醒

  

关于逻辑的更多信息

作为团队所有者的用户(=注册用户)将具有状态" user" 被称为合作伙伴的用户将拥有状态"合作伙伴",但来自用户类

如此说,一个用户,将能够创建多个合作伙伴,并且这些合作伙伴可能拥有相同的电子邮件(假设他们不在同一个团队中)。 我可以通过查找或创建来解决这个重复问题,因为所有合作伙伴都是由同一个用户创建的。

现在,想象很多用户都有共同的合作伙伴。 User1创建partner@gmail.com,User2创建partner@gmail.com 在这里,Devise将对其进行否决和封锁创作。

  

为什么我要为每个人保留合作伙伴,为什么我要保留   伙伴&用户使用相同的电子邮件?

- >合伙人有个人资料我希望用户能够为合作伙伴创建他想要的个人资料(化身等)。

- >合作伙伴可以在具有不同个人资料职业的不同团队中工作(比如说quaterback,或类似的东西),因此每个用户都可以为独特的partner@email.com创建自己的个人资料

- >如果用户注册(成为所有者,某种官方个人资料),并且在少数团队中作为合作伙伴出现,那么团队的所有者就会被要求从他创建的那个到#的swich个人资料34;官方一个"

我同意,这有点复杂。

现在,我存储"所有者"用户模型中专用行中的状态。 我和卡片和合作伙伴之间有多对多的关系。 通过这种方式,我可以轻松地使用他的新官方资料"更新partner_id。 id,如果用户请求,则删除"非官方"用户模型中的配置文件

我的问题实际上是使用角色进行Devise身份验证,以阻止合作伙伴登录尝试(以下部分回答)和电子邮件唯一性。

我希望我的解释清楚,我为我糟糕的英语道歉。

非常感谢你。

亲切的问候

1 个答案:

答案 0 :(得分:0)

你在这里提到的方法很好。您可以在同一个User表中拥有合作伙伴和用户。据我了解user has_many teams and team belongs_to user 。用户将是团队的所有者或合作伙伴。

因此,当用户添加合作伙伴时,只需创建一个方法来处理用户创建。还有一个包含user_id,team_id和user_role('user'或'partner')的表

假设使用的db是sql,

    class Team < ActiveRecord::Base
      has_many :teams_users
      has_many :users, :through => :team_users
    end

    class TeamUsers < ActiveRecord::Base
      belongs_to :team
      belongs_to :user
    end

    class User < ActiveRecord::Base
      has_many :teams_users
      has_many :teams, :through => :teams_users
    end

Devise需要密码,因此您可以从服务器端设置密码和password_confirmation。不要向用户发送邮件,因为您要避免使用默认设置的身份验证方式。在用户属性中设计商店confirmed_at,当用户点击确认链接时,该属性设置有时间戳。 Update this confirmed_at 从后端直接添加用户或根据您的要求。注册合作伙伴的电子邮件ID后,密码设置和确认__可用,合作伙伴帐户将处于活动状态。

当用户尝试以合作伙伴或用户身份注册/登录时,让我们看看第二部分。要处理此问题,请更改用户的sign_in行为。当用户尝试sign_up时,继承设计控制器并从users_team表中检查用户角色。有一个更清晰的想法,如果用户在两个不同的团队中有两个角色将会令人困惑。

即使用户状态是合作伙伴,也不应创建新帐户,因为默认情况下设计会将电子邮件ID视为唯一,并且因为已创建用户对象,除非您尝试更改此设置。在这两种情况下发送密码提醒看起来仍然很好,您可以根据应用程序的需要处理功能。