Skip to content
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

[5.8] Add a 'manage' default policy #28654

Merged
merged 3 commits into from May 30, 2019

Conversation

Projects
None yet
5 participants
@browner12
Copy link
Contributor

commented May 29, 2019

In our normal resource controller, we have index, create, store, edit, show, update, and destroy.

Our default policy has methods that correspond to most of these methods.

view --> show
create --> create and store
update --> edit and update
delete --> destroy

The one clear omission is we have no default policy that corresponds to the index method. The index method traditionally contains a list of all items of a particular Model.

I'm proposing a new default policy called manage that can be used to determine if a User is allowed to access the index resource route.

add a 'manage' default policy
In our normal resource controller, we have `index`, `create`, `store`, `edit`, `show`, `update`, and `destroy`.

Our default policy has methods that correspond to most of these methods.

`view` --> `show`
`create` --> `create` and `store`
`update` --> `edit` and `update`
`delete` --> `destroy`

The one clear omission is we have no default policy that corresponds to the `index` method. The `index` method traditionally contains a list of all items of a particular Model.

I'm proposing a new default policy called `manage` that can be used to determine if a `User` is allowed to access the `index` resource route.
@Christophvh

This comment has been minimized.

Copy link

commented May 29, 2019

Good idea. But I would call it list. All the words can be seen as permissions:
show, create, store, edit, update could be permissions if we add the model name. Manage seems like a permission where you can manage a complete model. 'List' would suggest you can only show a list of the items.

@browner12

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2019

Definitely not opposed to a name change. Thanks for the feedback.

@bonzai

This comment has been minimized.

Copy link
Contributor

commented May 29, 2019

@devcircus

This comment has been minimized.

Copy link
Contributor

commented May 29, 2019

This was intentionally removed a while back. Taylor has commented why. Not where I can dig for it right now.

@bonzai

This comment has been minimized.

Copy link
Contributor

commented May 29, 2019

I know (see link below), but what's the point of the manage policy, if it won't be used by the framework itself?

@taylorotwell

This comment has been minimized.

Copy link
Member

commented May 30, 2019

The reason it was omitted is because it's not as commonly used. If you have a list of comments you would typically just filter the comments the user is allowed to see in the query you run against the database.

However, there are sometimes places where this makes sense. I think I have done it once myself. I would not call it manage though... the suggestion of list was a bit better.

use the 'list' suggestion
also fixed the comment to use the Plural version of the model name.
@browner12

This comment has been minimized.

Copy link
Contributor Author

commented May 30, 2019

I'm good with 'list' as long as we don't have any conflicts with the PHP native list.

I will say personally I use this everywhere, especially on an administrative backend. I would agree on the frontend you'd only want to list things that belong to a user. A user's comments, a user's payments, etc. But on the backend, as an administrator, you would want to see everything. All the Users, all the Comments, all the Payments. But you may selectively allow different administrative users to access different lists, based on their role.

If this PR gets accepted, I can make the changes in AuthorizesRequest and Gate.

@bonzai

This comment has been minimized.

Copy link
Contributor

commented May 30, 2019

Laravel Nova uses viewAny method, so maybe it's a good to use it instead of list?

@taylorotwell

This comment has been minimized.

Copy link
Member

commented May 30, 2019

Ah yes, viewAny... probably worth keeping that to be consistent.

browner12 added a commit to browner12/framework that referenced this pull request May 30, 2019

@taylorotwell taylorotwell merged commit 9c93f77 into laravel:5.8 May 30, 2019

2 checks passed

continuous-integration/styleci/pr The analysis has passed
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@browner12 browner12 deleted the browner12:patch-2 branch May 30, 2019

timacdonald added a commit to timacdonald/framework that referenced this pull request Jun 2, 2019

update Gate `resource` method
this goes along with PR laravel#28654

BafS added a commit to BafS/framework that referenced this pull request Jun 4, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.