-
-
Notifications
You must be signed in to change notification settings - Fork 707
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
[DFC] add/delete enterprise to enterprise group #12024
[DFC] add/delete enterprise to enterprise group #12024
Conversation
plus documentaion
54f2fc8
to
5cd5681
Compare
Plus documentation
5cd5681
to
92921c8
Compare
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.
Nice and clean implementation!
Only one request for change.
engines/dfc_provider/app/controllers/dfc_provider/enterprise_groups/affiliated_by_controller.rb
Outdated
Show resolved
Hide resolved
engines/dfc_provider/app/controllers/dfc_provider/enterprise_groups/affiliated_by_controller.rb
Outdated
Show resolved
Hide resolved
engines/dfc_provider/spec/requests/enterprise_groups/affiliated_by_spec.rb
Outdated
Show resolved
Hide resolved
`<<` operator already save the the association to the database
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.
Nicely done! I think this is good to go.
I do have a query about the authorisation check though...
@@ -8,6 +8,7 @@ class ApplicationController < ActionController::Base | |||
protect_from_forgery with: :null_session | |||
|
|||
rescue_from ActiveRecord::RecordNotFound, with: :not_found | |||
rescue_from CanCan::AccessDenied, with: :unauthorized |
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.
Do none of the existing dfc controllers check authorisation already? Maybe they should?!
I'm guessing that most/all of the api read and write actions already filter records according to the user's enterprises, but is it worth covering the potential holes... or am I missing something?
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 haven't used CanCan for these checks until now. As you guessed, we used the users's scopes to access the right data.
I personally dislike CanCan as it adds complexity and I always find it difficult to see which rules apply to the current user. Looking for records in the right scopes makes any further authorisation unnecessary and it seems more efficient to me.
That said, sometimes the authorisation step is a bit more complicated and when you need to perform the same in several places then it's good to have a single source of truth. CanCan does have its place there.
Spree also used it to check every action and you had to allow everything with abilities before a user could access it. That's good security practice but it made the ability model unnecessarily big, I think.
Is this worth a chat in our next meeting?
What? Why?
Allow a group owner to add/remove an enterprise to a group.
What should we test?
Release notes
Changelog Category (reviewers may add a label for the release notes):
The title of the pull request will be included in the release notes.