AO3-6218 Allow certain admins to access all collection and challenge pages usually reserved for owners#5694
Conversation
…pages usually reserved for owners
Bilka2
left a comment
There was a problem hiding this comment.
Thanks for adding the tests, I'm finally here for the updated review
| And I invite the work "Test Work" to the collection "Moderated Collection" | ||
| When I am logged in as a "support" admin | ||
| And I view the awaiting collection approval collection items page for "Moderated Collection" | ||
| Then I should not see "You don't have permission" |
There was a problem hiding this comment.
I tried this test locally without the changes in this PR and found it passing because the collection search error overrides this flash message. To get the flash message to show up, all indexing jobs have been run has to be done after creating the collection to get rid of the search error.
But I'd prefer to try to check for something else here, since that error also wouldn't show up if Support admins were forbidden from viewing the page like tag wrangling admins are down below. Maybe add the paths to paths.rb and then check with I should be on ...? Or check text on the page, though I'm guessing you would've gone for that if it had been viable...
| Scenario: Policy and abuse admin can access collection pages | ||
| Given I have a collection "PAB Collection" | ||
| And I am logged in as a "policy_and_abuse" admin | ||
| When I go to "PAB Collection" collection edit page | ||
| Then I should see "Edit Collection" | ||
| When I go to the "PAB Collection" participants page | ||
| Then I should see "Members of" | ||
|
|
||
| Scenario: Superadmin can access collection pages | ||
| Given I have a collection "Super Collection" | ||
| And I am logged in as a super admin | ||
| When I go to "Super Collection" collection edit page | ||
| Then I should see "Edit Collection" | ||
| When I go to the "Super Collection" participants page | ||
| Then I should see "Members of" |
There was a problem hiding this comment.
This is fine to keep here since it's only two roles, but for the future: You can work with Scenario Outline and make the role a parameter, some other tests do that for example. Though I think in this case we don't have to exhaustively check every role since they behave the same and this is mostly about making sure the views don't error, so the way you organized this here is just fine
| And I sign up for "GE Requests" with combination A | ||
| When I am logged in as a "support" admin | ||
| And I go to the "GE Requests" requests page | ||
| Then I should not see "You are not allowed to view the requests summary!" |
There was a problem hiding this comment.
Same issue with this test not failing without the changes due to the error not showing up as above
| And I open signups for "GE Matching" | ||
| When I am logged in as a "support" admin | ||
| And I go to "GE Matching" gift exchange matching page | ||
| Then I should not see "Sorry, you don't have permission" |
| Then I should see "Sign-ups" | ||
| And I should see "signer1" | ||
|
|
||
| Scenario: Support admin can access an individual sign-up |
There was a problem hiding this comment.
(this organization is nice for review, but I also wouldn't mind if you combine this test and the previous one)
| And I press "Generate Potential Matches" | ||
| Then I should see "Please log out of your admin account first!" | ||
|
|
||
| Scenario: Support admin can access Assignments page |
There was a problem hiding this comment.
This is missing the test for accessing an individual assignment
| And I sign up for Battle 12 with combination A | ||
| When I am logged in as a "support" admin | ||
| And I go to the "Battle 12" claims page | ||
| Then I should not see "Sorry, you don't have permission" |
There was a problem hiding this comment.
The error message problem again :(
Pull Request Checklist
as the first thing in your pull request title (e.g.
AO3-1234 Fix thing)until they are reviewed and merged before creating new pull requests.
Issue
https://otwarchive.atlassian.net/browse/AO3-6218
Additional Notes
Failed on QA. Made necessary changes as per comments on jira.
Purpose
Allow admins with
support,policy_and_abuse, orsuperadminroles to access owner/maintainer collection and challenge pages for viewing/troubleshooting, without granting write permissions.Implemented via shared controller helpers and action-level filter changes so read routes are opened for those roles while create/update/destroy paths remain owner/maintainer-only.
Testing Instructions
Automated coverage was added/updated for the affected controllers to verify:
(Functional QA flow is already documented in the Jira ticket.)
Credit
varram (he/him)