Fix access to the version history of organization-level roles #2654
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checklist
master
branch.Short description of what this resolves, changes proposed
The tests of the version history of organization-level roles are currently failing. In trying to understand why, I encountered several complications:
The tests expect the version history of organization-level roles to be accessible by conference organizers. This surprised me; I expected that organization administrators should have this access, not conference organizers.
Proposed change: Test as an organization administrator.
Regardless of that decision, currently neither organization administrators nor conference organizers have access, due to two independent bugs:
No permission has been granted to access versions of organization-level roles.
Proposed change: Grant permission.
In the metadata of versions of organization-level roles, organization IDs are conflated with conference IDs; affiliation with organization n is recorded as affiliation with conference n. (Confusing name conference_id in versions table #1728)
Proposed change: Distinguish between organization IDs and conference IDs.
The tests that should have caught this return false negatives under SQLite. In this test configuration, the organization and conference happen to have numerically equal IDs, so their conflation goes undetected.
Proposed change: I don't have any good ideas about how to detect this kind of mistake in the future. Maybe randomize IDs by prepopulating tables with filler rows? Or enforce unique IDs upon creation in factories?
I'm not confident about these changes. I don't fully understand the relationship between the
is_admin
flag and theorganization_admin
role, and I'm unclear about what theconference_id
version metadata was supposed to be, e.g. should it be a polymorphic association instead?