fix: allow assigning a bed to a member who already holds a lease#31
Merged
Conversation
Members are permitted to hold more than one leased bed, but the admin
assign endpoint rejected anyone with an existing non-released lease
("That member already holds a leased bed."). Removed the per-member
guard. Bed-level double-booking is still prevented by IsBedOccupiedAsync,
and the member status/card path already renders a list of leases.
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.
What
Removed the per-member guard in
AssignBedEndpointthat rejected assigning a bed to any member already holding a non-released lease ("That member already holds a leased bed.").Why
Members are allowed to hold more than one leased bed at a time, but the admin "assign bed" flow (e.g. from the pending applications card) blocked it. The guard was the only thing enforcing a one-bed-per-member rule; there is no DB constraint behind it.
Notes for reviewers
IsBedOccupiedAsync(checks the bed, not the member), which is untouched.GetMyStatusAsync) and profile card already return/render a list of leases, so no downstream code assumed a single lease.ApplyForBedEndpointstill blocks a new self-application while anAwaitingPaymentlease exists — that's a separate rule (no stacking unpaid applications) and was intentionally left in place.