The [`ArticlePolicy#moderate?`][1] method answers the questions around article
moderation.
At present this change does not introduce any significant changes (aside
from the JS logic loop). The next "step" is to adjust the
`ArticlePolicy#moderate?` method to test if the user has a moderator
role.
Further, we'd need to see what is available on the action panel.
Related to forem/forem#17606
[1]:5ac3216a5a/app/policies/article_policy.rb (L160-L174)
26 lines
1,023 B
Ruby
26 lines
1,023 B
Ruby
require "rails_helper"
|
|
|
|
RSpec.describe AsyncInfo do
|
|
describe "#to_hash_for" do
|
|
subject(:async_info) { described_class.to_hash(user: user, context: context) }
|
|
|
|
let(:user) { create(:user) }
|
|
let(:feed_style_preference) { Settings::UserExperience.feed_style }
|
|
let(:context) { AsyncInfoController.new }
|
|
|
|
# Because of edge caching considerations, I'm short-circuiting that check. For the applicable
|
|
# controller, we should always have an authenticated user and it is not edge cached.
|
|
before { allow(context).to receive(:current_user).and_return(user) }
|
|
|
|
it "has a policies key with an array of policies", :aggregate_failures do
|
|
policies = async_info.fetch(:policies)
|
|
expect(policies.length).to be > 0
|
|
|
|
# All policy keys will have dom_class and forbidden
|
|
expect(policies.map(&:keys).uniq).to eq([%i[dom_class visible]])
|
|
|
|
expect(policies.map { |p| p.fetch(:dom_class) }.sort)
|
|
.to eq(%w[js-policy-article-create js-policy-article-moderate])
|
|
end
|
|
end
|
|
end
|