-
-
Notifications
You must be signed in to change notification settings - Fork 61
Adding Pundit, applies to User and Person models #514
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
app/controllers/people_controller.rb
Outdated
| @@ -1,4 +1,5 @@ | |||
| class PeopleController < ApplicationController | |||
| before_action :authenticate_user! | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't this already in ApplicationController?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah -- whoops! Gotta remove that :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like it! I can take this one out
| before_action :authenticate_user! | ||
| before_action :set_person, only: [:show, :edit, :update, :destroy] | ||
|
|
||
| def index |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this have authorize @people?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe -- I'm still learning how to setup Pundit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shrug Maybe? We don't really have a lot of info about the expectations of how this stuff works so I wasn't sure how the /people route was intended to be used. Should it be locked down?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IME, authorizing a collection isn't very useful, but verifying that the collection was generated using a policy scope is. The best way to do that is to let the verify_policy_scoped after_action catch it if you forget.
app/controllers/users_controller.rb
Outdated
| end | ||
| end | ||
|
|
||
| # NOTE: I'm not entirely sure this is used at all. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, i'm considering a new controller so admins can do create user+person in one step and removing this from here bc it's not used/useable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't get the tests for it to run, or even route to it so that I can insert a byebug! So I'm going to remove it.
app/policies/person_policy.rb
Outdated
| @record = record | ||
| end | ||
|
|
||
| def edit? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we get this from ApplicationPolicy? not sure what standard is for adding to child policies
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think originally I had changed it to something else and was just changing it back here. I realize it's redundant, but it also explicitly declares the expected behavior (were ApplicationPolicy to be changed later, that would create problems here). My personal preference for stuff like this is to have the default behaviors as a safety net but to explicitly define things that are definitely used.
I'm happy to defer to yours / the team's preferences on this though!
app/policies/user_policy.rb
Outdated
| end | ||
|
|
||
| def update? | ||
| user == record || user.sys_admin_role? || user.admin_role? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should users bc able to edit their own roles tho? maybe dropdown is only their permission level and lower?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah I think the controller layer is the right place to set that
| @@ -0,0 +1,2 @@ | |||
| <h1>Sorry, you aren't authorized to do that.</h1> | |||
| <p>If you think this is wrong, please contact your administrator.</p> No newline at end of file | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🙌
| @@ -1,15 +1,25 @@ | |||
| <div class="title is-3">Profile</div> | |||
| <div class="title is-5"><%= @user.person&.name %></div> | |||
| <div class="title is-3">Account Settings</div> | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
| other: Match Feedback | ||
| zero: Match Feedback | ||
| pundit: | ||
| default: 'You cannot perform this action.' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
totally! wtg w the details!
spec/requests/people_spec.rb
Outdated
| describe "POST /create" do | ||
| subject { post people_url, params: { person: valid_attributes } } | ||
|
|
||
| it_behaves_like "basic user authorization required" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool! lsn!
spec/requests/people_spec.rb
Outdated
|
|
||
| before(:each) { create(:person, user_id: self.id) } | ||
|
|
||
| # TODO: What happens when the user already has a record created for themselves |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤷♀️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
haha 😆
This could be decided on later, it was just something that came to mind while I was doing it
spec/requests/people_spec.rb
Outdated
|
|
||
| context "when attempting to create a person for someone else's user ID" do | ||
| let(:other_user) { create(:user) } | ||
| subject { post people_url, params: { person: valid_attributes.merge(user_id: other_user.id) } } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
| @@ -0,0 +1,54 @@ | |||
| RSpec.shared_examples 'redirects without authorization' do | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💃 awesome!
|
ack! didn't notice the |
|
This is looking great @armahillo ❤️💥. One thought on testing: i wonder if it would be sufficient to directly test policies ( I'm guessing it will be easier to test policy behavior w/o having to go through the controller and could also lead to less duplication/boiler-plate across request specs (most controllers will behave exactly the same based on whether the policy throws or not). |
solebared
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking great!! 🙏🏾 🙌🏾
A few thoughts and questions inline.
| attr_reader :acting_user, :record | ||
|
|
||
| def initialize(acting_user, record) | ||
| @acting_user = acting_user |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think i understand the concept of an acting_user and like the term. I do wonder however if there's value in sticking with current_user since that's an existing concept we already have to incorporate from devise. Is there a conceptual or concrete difference between them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or alternatively, use plain user within policies since that seems to be the defacto norm (used in pundit docs).
| RSpec.shared_context "acting as signed-in user" do | ||
| let(:acting_user) { FactoryBot.create(:user) } | ||
| end | ||
|
|
||
| RSpec.shared_context "acting as sysadmin" do | ||
| let(:acting_user) { FactoryBot.create(:user, :sys_admin) } | ||
| end | ||
|
|
||
| RSpec.shared_context "acting as admin" do | ||
| let(:acting_user) { FactoryBot.create(:user, :admin) } | ||
| end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have to admit, i've grown to dislike globally shared contexts, particularly those that define lets referenced in specs. I find the cognitive load involved in jumping back and forth between spec, local context, shared context and sometimes other connected contexts to be quite heavy.
I really like the local ones in user|person_policy_spec because the context names provide more meaning that the lets therein. These ones definitely also provide meaning, but i'm finding it difficult have certainty just from the names exactly what they do. Perhaps this is case of needing to get used to the terminology ('acting-as', 'signed-in', etc) and once i do, my mind won't want to jump around. OTOH, i wonder if inlining these ends up being easier to grok, even at the cost of some more duplication?
The ones below seem widely used in request specs so probably worth their weight.
| # By default, we group permissions into: | ||
| # - read (show) | ||
| # - add (new/create) | ||
| # - change (edit/update) | ||
| # - delete (destroy) | ||
| # We recommend that you override read?/add?/change?/delete? rather than action-level policies. | ||
| def show?; read?; end | ||
| def create?; add?; end | ||
| def new?; add?; end | ||
| def update?; change?; end | ||
| def edit?; change?; end | ||
| def destroy?; delete?; end | ||
|
|
||
| # We default all permissions to false, and expect you to override as needed. | ||
| private def read?; false; end | ||
| private def add?; false; end | ||
| private def change?; false; end | ||
| private def delete?; false; end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Conflicts resolved: * Gemfile * Gemfile.lock * app/controllers/public_pages_controller.rb
|
@bhaibel , i noticed this branch was showing some minor conflicts against |
2840b12 to
83314ee
Compare
Co-authored-by: maebeale <maebeale@gmail.com> Conflicts: app/controllers/admin_controller.rb app/controllers/announcements_controller.rb app/controllers/application_controller.rb app/controllers/asks_controller.rb app/controllers/categories_controller.rb app/controllers/communication_logs_controller.rb app/controllers/community_resources_controller.rb app/controllers/contact_methods_controller.rb app/controllers/contributions_controller.rb app/controllers/custom_form_questions_controller.rb app/controllers/donations_controller.rb app/controllers/feedbacks_controller.rb app/controllers/form_questions_controller.rb app/controllers/forms_controller.rb app/controllers/history_logs_controller.rb app/controllers/listings_controller.rb app/controllers/location_types_controller.rb app/controllers/locations_controller.rb app/controllers/matches_controller.rb app/controllers/mobility_string_translations_controller.rb app/controllers/offers_controller.rb app/controllers/organizations_controller.rb app/controllers/people_controller.rb app/controllers/positions_controller.rb app/controllers/public_controller.rb app/controllers/service_areas_controller.rb app/controllers/shared_accounts_controller.rb app/controllers/shift_matches_controller.rb app/controllers/shifts_controller.rb app/controllers/software_feedbacks_controller.rb app/controllers/submission_response_imports_controller.rb app/controllers/submission_responses_controller.rb app/controllers/submissions_controller.rb app/controllers/system_locales_controller.rb app/controllers/system_settings_controller.rb app/controllers/teams_controller.rb app/controllers/users_controller.rb spec/factories/users.rb spec/requests/people_spec.rb
These are controllers that were added since the pundit branch was worked on.
0058ed4 to
d852faa
Compare
|
Scenarios tested (manually):
|
maebeale
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
YESSSSS!!!!!!
THANK YOU @Exbinary @svileshina @armahillo @bhaibel @h-m-m !!!!!
Will update this shortly.