Show period membership on the contribution manager#376
Merged
Conversation
The Member/User chip on the contribution manager read the user's current MEMBER role, so a row's membership state did not reflect the contribution period being viewed: someone who was a member during an older period but is not one now showed as User, and vice versa. The contribution manager now fetches the memberships overlapping the selected period (findMemberships with the period's from/to range, the same query the member manager uses) alongside the period's contributions, and derives the set of user ids that held a membership during it. That set is threaded through the contribution list to each row, which derives wasMemberDuringPeriod from it; the chip and its colour come from that instead of the user's roles. The membership set is cleared when no period is selected and is subject to the same stale-response guard as the contributions, so a slow fetch for a deselected period cannot overwrite the current one.
Add coverage for the period-membership behaviour: the contribution manager calls findMemberships with the selected period's range and forwards the resulting user-id set to both lists, clears it on deselection and when a period has no memberships, and ignores a stale response from a previously selected period. The list forwards membership state per row, and the row chip is driven by the period membership set rather than the user's roles (a current member absent from the period shows User; a non-member present in the period shows Member; an empty roles array still renders User).
jorisjonkers-dev-agents
Bot
force-pushed
the
feature/contribution-manager-period-membership
branch
from
4b84a73 to
27fb681
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Depends on #374 and must merge after it. This branch builds on the contribution-manager restructure in #374, so until that merges this PR's diff also includes #374's commit; it collapses to just this change once #374 lands on main.
Problem
The Member/User chip on the contribution manager read the user's current
MEMBERrole, so a row's membership state did not reflect the contribution period being viewed. Someone who was a member during an older period but is not one now showed as "User", and a current member showed as "Member" even for a period predating their membership.Change
The contribution manager now fetches the memberships overlapping the selected period —
findMembershipswith the period'sfrom/torange, the same query the member manager already uses — alongside the period's contributions. From that response it derives the set of user ids that held a membership during the period.That set is threaded through the contribution list to each row, which derives
wasMemberDuringPeriodfrom it; the chip label and colour come from that set instead ofuser.roles. The set is cleared when no period is selected, and is covered by the same stale-response guard as the contributions, so a slow fetch for a since-deselected period cannot overwrite the current one. Both fetches run together viaPromise.all.No backend change is required:
MembershipSpecifications.timeOverlapalready returns the memberships whose interval overlaps the queried range.Tests
ContributionManager.test.tscovers the membership query being issued with the period range, the set being forwarded to both lists, clearing on deselection and on a period with no memberships, and a stale response not overwriting the current period.ContributionUserList.test.tsasserts per-row forwarding for a member and a non-member.ContributionUserRow.test.tsproves the chip is driven by the period set, not roles (current member absent from the period shows "User", non-member present shows "Member", empty roles still renders "User").Verified from
services/frontend:yarn typecheck,yarn lint, andyarn test:unit(315 tests) pass.