Skip to content

Conversation

@armahillo
Copy link
Collaborator

Will update this shortly.

@@ -1,4 +1,5 @@
class PeopleController < ApplicationController
before_action :authenticate_user!
Copy link
Collaborator

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?

Copy link
Collaborator Author

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 :(

Copy link
Collaborator Author

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
Copy link
Collaborator

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?

Copy link
Collaborator Author

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

Copy link
Collaborator Author

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?

Copy link

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.

end
end

# NOTE: I'm not entirely sure this is used at all.
Copy link
Collaborator

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

Copy link

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.

@record = record
end

def edit?
Copy link
Collaborator

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

Copy link
Collaborator Author

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!

end

def update?
user == record || user.sys_admin_role? || user.admin_role?
Copy link
Collaborator

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?

Copy link
Collaborator Author

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
Copy link
Collaborator

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>
Copy link
Collaborator

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.'
Copy link
Collaborator

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!

describe "POST /create" do
subject { post people_url, params: { person: valid_attributes } }

it_behaves_like "basic user authorization required"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool! lsn!


before(:each) { create(:person, user_id: self.id) }

# TODO: What happens when the user already has a record created for themselves
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤷‍♀️

Copy link
Collaborator Author

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


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) } }
Copy link
Collaborator

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💃 awesome!

@maebeale
Copy link
Collaborator

ack! didn't notice the draft tag. my b!!!

@solebared
Copy link
Collaborator

This is looking great @armahillo ❤️💥.

One thought on testing: i wonder if it would be sufficient to directly test policies (spec/policies/...) and verify controller coverage by getting pundit to ensure authorization happened.

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 solebared changed the base branch from master to main September 2, 2020 23:44
@svileshina svileshina linked an issue Sep 4, 2020 that may be closed by this pull request
Copy link
Collaborator

@solebared solebared left a 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
Copy link
Collaborator

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?

Copy link
Collaborator

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).

Comment on lines +1 to +11
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
Copy link
Collaborator

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.

Comment on lines +49 to +66
# 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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@solebared solebared marked this pull request as ready for review September 13, 2020 16:10
Conflicts resolved:
* Gemfile
* Gemfile.lock
* app/controllers/public_pages_controller.rb
@solebared
Copy link
Collaborator

@bhaibel , i noticed this branch was showing some minor conflicts against main.
I went ahead and merged it in, resolving conflicts, with the hope this is more helpful than annoying! 🤞🏾😅

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.
@solebared
Copy link
Collaborator

solebared commented Jan 18, 2021

Scenarios tested (manually):

  • Announcements
    • /announcements is protected
    • /announcements_list is accessible
    • Create new announcement as a guest
    • Approve an annoncement as an admin
  • Community Resources
    • /community_resources is protected
    • /community_resources_list is accessible
    • Create new resource as a guest
    • Cancel from /new fails for a guest -- consistent with main
  • Offer|Ask forms
    • Create new ask|offer as a guest
    • /submissions is protected
  • Contributions
    • dispatch mode
      • Guest is not able to see /contributions
    • p2p mode
      • Guest is able to see /contributions
      • Able to click 'View' on a contribution
      • Claim requires login -- consistent with main
      • Respond button is visible to guests -- consistent with main
  • Matches
    • /matches is protected
  • User
    • Able to login and logout
    • Sign up is still disabled
    • Admin is able to edit a user account
    • Admin is able to delete a user account
    • Not able to create a new user -- consistent with main
  • People
    • Admin is able to add a person record
    • Admin is able to show and edit a person record
    • Guest is not able to access /people or /people/:id

Copy link
Collaborator

@maebeale maebeale left a 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 !!!!!

@solebared solebared merged commit e2de56d into main Jan 19, 2021
@solebared solebared deleted the 61-add-pundit branch January 19, 2021 15:18
@solebared solebared mentioned this pull request Jan 26, 2021
30 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add Pundit

6 participants