ruby-on-rails – 记录更改由特权用户批准;它就像版本化和批准一样

ruby-on-rails – 记录更改由特权用户批准;它就像版本化和批准一样,第1张

概述我要求在对这些更改进行批准之前,对记录的某些属性更改不会反映在用户界面中.此外,如果对批准的记录进行了更改,则将在批准之前向用户显示该记录. 我的第一次尝试…… 是去了一个版本控制插件,如paper_trail,acts_as_audited等,并将一个已批准的属性添加到他们的版本模型中.这样做不仅可以让我能够“回滚”记录的版本,而且还应该允许我区分版本是否已被批准. 我一直在努力研究这段思路,我 我要求在对这些更改进行批准之前,对记录的某些属性更改不会反映在用户界面中.此外,如果对批准的记录进行了更改,则将在批准之前向用户显示该记录.

我的第一次尝试……

是去了一个版本控制插件,如paper_trail,acts_as_audited等,并将一个已批准的属性添加到他们的版本模型中.这样做不仅可以让我能够“回滚”记录的版本,而且还应该允许我区分版本是否已被批准.

我一直在努力研究这段思路,我一直遇到的问题是在用户方面.也就是说,如何查询已批准记录的集合?我可以(并尝试)编写一些获取记录集合的辅助方法,然后循环遍历它们以查找记录的“已批准”版本.我对此的主要抱怨是数据库命中数量的增长速度有多快.我的下一步尝试是做如下的事情:

Version.  where(:item_type => MyModel.name,:approved => true).  group(:item_type).collect do |v|  # like the 'reify' method of paper_trail  v.some_method_that_converts_the_version_to_a_record end

因此,假设some_method …调用没有访问数据库,我们最终会得到我们感兴趣的数据.我遇到的主要问题是我不能使用这个“finder”作为范围.也就是说,我无法在此查找中添加其他范围以进一步缩小我的结果范围.例如,我的记录也可能有一个很酷的范围,只显示记录,其中:cool =>真正.理想情况下,我想查看我的记录为MyModel.approved.cool,但在这里我想我必须得到我的批准模型的集合,然后循环它们的酷的将导致至少有一堆无记录地在内存中初始化的记录.

我的下一次尝试……

涉及创建一种特殊类型的“待处理记录”,它基本上有助于记录的“潜在”变化.因此,在用户端,您可以像往常一样查找任何您想要的内容.无论何时应用待处理的记录!(ed)它只会对实际记录进行那些更改,并且一切都很好……除了大约30分钟后我意识到如果“管理员”希望返回并且它会全部崩溃在批准之前为他的变化做出更多贡献.我想我唯一的选择是:

>强制管理员在制作其他更改之前批准所有更改(不会很好地进行…也不应该).
>尝试从“待处理记录”模型中读取更改并将其应用于现有记录而不保存.关于这个想法的东西听起来并不是很“正确”.

我希望有人就这个问题提出意见.我已经和它搏斗了一段时间,我似乎无法找到感觉正确的方式.我喜欢生活在“如果它难以理解它,你可能做错了”的口头禅.

这是踢我的尾巴……

解决方法 怎么样,创建一个关联:

class MyModel < AR::Base  belongs_to :my_model  has_one    :new_version,:class_name => MyModel  # ...end

进行编辑时,您基本上将现有对象克隆为新对象.关联现有对象和新对象,并在现有对象上设置has_edits属性,在新对象上设置pending_approval属性.

管理员批准后如何处理对象取决于您是否有其他依赖于原始模型ID的关联.

无论如何,您可以将查询减少到:

objects_pending_edits = MyModel.where("has_edits = true").all

然后使用任何给定的一个,您可以使用obj.new_version访问新的编辑.如果您真的想减少数据库流量,请加载该关联.

总结

以上是内存溢出为你收集整理的ruby-on-rails – 记录更改由特权用户批准;它就像版本化和批准一样全部内容,希望文章能够帮你解决ruby-on-rails – 记录更改由特权用户批准;它就像版本化和批准一样所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/langs/1293399.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-06-10
下一篇 2022-06-10

发表评论

登录后才能评论

评论列表(0条)

保存