【问题标题】:Validates acceptance always failing验证接受总是失败
【发布时间】:2011-06-12 09:57:09
【问题描述】:

我看不到我缺少什么,但显然有些地方不对。

在模型中:

validates :terms, :acceptance => true, :on => :update

尝试几个选项:

>> a = Factory(:blog_agreement)
=> #<BlogAgreement id: 54, terms: false, created_at: "2011-01-20 11:33:03", updated_at: "2011-01-20 11:33:03", accept_code: "fa27698206bb15a6fba41857f12841c363c0e291", user_id: 874>

>> a.terms
=> false

>> a.terms = true
=> true
>> a.save
=> false

>> a.terms = "1"
=> "1"
>> a.save
=> false

>> a.terms = 1
=> 1
>> a.save
=> false
>> a.errors.full_messages
=> ["Terms must be accepted"]

【问题讨论】:

    标签: ruby-on-rails validation


    【解决方案1】:

    更新答案..

    因此,问题在于将术语作为表中的实际列。通常 validates_acceptance_of 不使用这样的列,在这种情况下,它定义了一个属性访问器并将其用于验证。

    为了使 validates_acceptance_of 在映射到真实表列时起作用,需要传递 :accept 选项,例如:

    validates :terms, :acceptance => {:accept => true}
    

    原因与 Active Record 中的类型转换有关。当命名属性实际存在时,AR 会根据数据库列类型进行类型转换。在大多数情况下,接受列将被定义为布尔值,因此 model_object.terms 将返回 true 或 false。

    当没有 attr_accessor :terms 这样的列时,只需返回从 params 哈希传递给模型对象的值,该值通常是来自复选框字段的 "1"

    【讨论】:

    • 谢谢。嗬!是的,我没有意识到它适用于虚拟字段。但是,是的,Factory(:whatever) 创建了对象,然后我在上面的示例中对其进行了更新。
    • 酷。您可以保留 db 列中的术语并使用不同的验证器,但实际上,如果假设只有在接受条款时才能创建用户记录,那么实际上就不需要它了。
    • 啊,我的推理是对象由管理员创建,然后最终用户接受协议(因此仅在更新时验证条款)。我也确实想存储他们是否被接受。很酷,我可以从这里修复它,如果可行的话会非常简短和简单
    • 只是阅读 AcceptanceValidator 的代码,当属性映射到数据库列时,您似乎可以使用它。为此,您必须在声明验证时通过:accept =&gt; true。见:github.com/rails/rails/blob/master/activemodel/lib/active_model/…
    • 对于像我这样的人,相反,如果数据库中没有列,请将:acceptance =&gt; {:accept =&gt; true} 更改为:acceptance =&gt; true
    【解决方案2】:

    如果有人和我有同样的问题,我添加这个答案:

    我已添加到设备的注册表中:

    sign_up.html.erb

    <%= f.check_box :terms_of_service %>
    

    user.rb

    validates, :terms_of_service, acceptance: true
    

    我忘记在我的已配置_permitted_pa​​rameters 中添加 :terms_of_service 并且设计忽略了复选框状态。

    application_controller.rb

    before_filter :configure_permitted_parameters, if: :devise_controller?
    
    def configure_permitted_parameters
      devise_parameter_sanitizer.for(:sign_up) { |u| u.permit(:email, :password, :password_confirmation, :terms_of_service)}
    end
    

    configure_permitted_pa​​rameters 方法被设计用于知道除了电子邮件和密码之外还应该保存哪些参数。

    【讨论】:

    • 我试过你的答案,但没有得到想要的结果
    • 我需要进一步了解您的问题。您可以使用您的代码创建一个新问题并在此处发布网址。我很乐意为您提供帮助;)
    【解决方案3】:

    我必须使用这种格式:

    validates :accpeted_terms, :acceptance => {:accept => true}
    

    【讨论】:

    • 但很可能在您的验证属性中没有错字,因为它目前读取为accpeted_terms
    • 我在 postgres 中遇到了这个问题。 Rails 指南说接受:true 默认值为 ['1', true]。但是添加 (accept: true } 会有效地删除 '1' 作为可接受的值,并且它总是失败
    【解决方案4】:
    validates_acceptance_of :terms, :accept => true
    

    【讨论】:

    • 其他答案不适用于 Rails 3。这个答案完美。
    【解决方案5】:

    我在上面发现 Candland 的回答是在 Rails 3.1 中验证接受是正确的。这就是我设置我的 Rails 3.1.3 应用程序以将接受情况记录到数据库的方式。

    在迁移中,

    class AddTermsToAccount < ActiveRecord::Migration
      def change
        add_column :accounts, :terms_of_service, :boolean, :default => false
      end
    end
    

    在模型中,

    attr_accessible :terms_of_service
    validates :terms_of_service, :acceptance => {:accept => true}
    

    在表格中,

    <%= f.check_box :terms_of_service %>
    <%= f.label :terms_of_service %>
    

    【讨论】:

      【解决方案6】:

      我已经从 Angular JS 和 Rails 4 尝试过这个。带有 true 值的 Angular 发送参数,但 rails 无法识别 true

      它可以接收一个 :accept 选项,该选项确定将要接收的值 视为接受。它默认为“1”,可以很容易地 改变了。

      所以,我改成这样:

      class Person < ActiveRecord::Base
        validates :terms_of_service, acceptance: { accept: true }
      end
      

      如果您有默认参数是10。尝试这样做:

      class Person < ActiveRecord::Base
        validates :terms_of_service, acceptance: true
      end
      

      这是为了更多的文档。 acceptance validation。 希望对您有所帮助。

      【讨论】:

        【解决方案7】:

        对工厂的调用会创建记录,因此您对保存的后续调用实际上是更新,因此您的验证按预期失败。在没有工厂的情况下尝试它应该可以工作。

        【讨论】:

        • 但她正在接受条款,但验证仍然失败。
        【解决方案8】:

        如果您的视图中有一个基本复选框,例如

        <%= builder.check_box :agreement %>
        

        只要把这条线放在你的模型中

        validates :agreement, :acceptance => true
        

        使用 check_box 视图助手生成的默认“1”

        【讨论】:

          猜你喜欢
          • 2016-01-18
          • 2016-03-25
          • 2016-06-16
          • 1970-01-01
          • 1970-01-01
          • 2023-01-04
          • 2016-06-23
          • 2016-02-13
          相关资源
          最近更新 更多