-
Notifications
You must be signed in to change notification settings - Fork 124
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
[WIP] update AdminSetCreateService to create valkyrie resources #5083
Conversation
c20db89
to
6223a0b
Compare
this looks pretty great. if you can get it passing i'll take a final pass through and usher it through! thanks! |
c7f59cc
to
ea2030e
Compare
d0f31ec
to
a84f223
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.
this is looking pretty good to me!
the main substantive question i have is about the ::Ability
handling. i've feared that changes to ::Ability
on Collection
, AdminSet
and FileSet
might require some cleverness because ::Ability
belongs to the application. your thoughts would be helpful
end | ||
|
||
def ensure_manager! | ||
# TODO: Review for possible removal. Doesn't appear to apply anymore. | ||
# Even though the user can view this admin set, they may not be able to view | ||
# it on the admin page. | ||
authorize! :manage_any, AdminSet | ||
authorize! :manage_any, Hyrax::AdministrativeSet |
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.
can you say more about this?
do these two authorization checks return the same values already(?). will that be the case ::Ability
in general, or just the baseline Hyrax::Ability
setup? my intuition would be that we'd need to keep the existing check, but i could be 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.
Commit 'remove check for :ensure_manager! in admin_sets_controller' removed this check altogether along with the associate before_action
. I confirmed that tests pass and UI interactions behave as expected. See commit notes for more details.
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.
are we sure it's no longer needed? i'm not really understanding why that would be the case. if we were before rejecting requests from non-managers, i think we probably need to keep it? or if not, at least have a clear understanding of why the new auth pattern is non-breaking.
@@ -120,7 +120,9 @@ def ensure_viewer! | |||
end | |||
|
|||
def create_admin_set | |||
admin_set_create_service.call(admin_set: @admin_set, creating_user: current_user) | |||
# TODO: Should be able to remove the valkryie_resource check when create/edit form is updated |
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.
which form does this refer to? i'm not sure what action this todo points to as a next step.
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 removed the TODO. I also moved the conversion back and forth to private methods to make the method cleaner. When this is fully working with valkyrie, the conversion back and forth methods can be removed.
post :create, params: { admin_set: { title: 'Test title', | ||
description: 'test description', | ||
workflow_name: 'default' } } | ||
admin_set = assigns(:admin_set) | ||
expect(response).to redirect_to(edit_admin_admin_set_path(admin_set)) | ||
expect(response).to redirect_to(edit_admin_admin_set_path(admin_set.id.to_s)) |
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.
is the #to_s
needed? do the rails path helpers not handle 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.
I was able to remove this change. With the change to have the admin_set id return nil
instead of an empty string, this test began failing. The service was not set up to receive :call!
, so the test was actually not testing the create
process. You will see a change to the service in this test to mock Hyrax::AdminSetCreateService.call!
, which allows the create tests to pass.
099ee13
to
be9cc37
Compare
@no-reply Requested changes are complete and ready for review. |
Add… * .`find_or_create_default_admin_set` = replacement for `AdminSet.find_or_create_default_admin_set_id` * `.default_admin_set?(id:)` = replacement for `AdminSet.default_set?` * `.call!` - returns object instead of true/false returned by `.call` * `#create!` - returns object instead of true/false returned by `#create` Deprecate * `.create_default_admin_set` - use `.find_or_create_default_admin_set` instead Publish * update metadata when adminset created rc
…nSetCreateService.find_or_create_default_admin_set.id
…ativeSet This is required for the UI to work with the changes to create admin sets using the Hyrax::AdminSetCreateService which is updated to use Valkryie.
NOTE: Indexing will still run all objects via metadata_index_listener which responds to the same messages. Also, still runs `on_object_deleted` since it operates on `id` only and does not attempt to generate a path.
A TODO in the `AdminSetsController` suggested that `:ensure_manager!` is no longer needed. I removed the `before_action`, ran tests, and tested in the UI with the following steps. All look good. prereq * create admin user * create non-admin user 1. login as admin 2. create new admin set 3. add non-admin user as a Manager 4. logout and log back in as non-admin user 5. navigate to Dashboard -> Collections -> Managed Collection (tab) 6. click name of created admin set 7. click Edit 8. modify the description 9. Save 10. navigate to Dashboard -> Collections -> Managed Collection (tab) 11. click name of created admin set 12. confirm that the description was updated Based on these results, it appears that the TODO is correct and this check can be removed.
makes a few additional minor adjustments based on PR feedback
be9cc37
to
109c7e7
Compare
CLOSING - superseded by PR #5224 |
Work In Progress -- DO NOT MERGE
While investigating
ensure_manager!
, it became clear that the permission_template is not adding the access rights as expected. The code to add the access rights needs to be reviewed and corrected to be sure the rights are assigned.See PR #5093 -- This PR adds feature tests that demonstrates it is safe to remove
ensure_manager!
andensure_viewer!
Add…
find_or_create_default_admin_set
= replacement forAdminSet.find_or_create_default_admin_set_id
.default_admin_set?(id:)
= replacement forAdminSet.default_set?
.call!
- returns object instead of true/false returned by.call
#create!
- returns object instead of true/false returned by#create
Deprecate...
.create_default_admin_set
- use.find_or_create_default_admin_set
insteadReplace uses of...
@samvera/hyrax-code-reviewers