Repository navigation
fix(integrations): make an allocation's assignable flag toggleable pe… - #194
Merged
Merged
Conversation
…r course
Pathment's mentor course picker came back empty for the Pathment org while
all 22 courses sat in its catalog. The integration itself was healthy:
credentials verified, the right org resolved, and GET /integrations/v1/courses
answered 200 {"courses":[]}. GET /integrations/v1/allocations showed why --
every row was PUBLISHED, unexpired and had 400 free seats, but carried
isAllowed: false, which is the one condition listAllocatedCourses filters on.
isAllowed could only be set by the bulk allocation form's single checkbox,
which applies to every selected course at once, so one save with it unticked
disabled a whole catalog silently. The table still showed those courses "In
catalog" with their seats and expiry; the only hint was a quiet "No" in the
Allowed column, with no control to change it. The leaderboard flag in the next
column already had a per-row toggle. This one did not, so the only way back
was re-selecting every course in the bulk form.
Add PATCH /organizations/:orgId/allocations/:courseId/allowed and a per-row
toggle in the admin table, mirroring the leaderboard control. The write is
audited under organization.allocate, because it grants or withdraws access.
Rename the column to Assignable and show a destructive "Not assignable" badge
when the flag is off, so a disabled allocation reads as a fault rather than as
a neutral status.
Tests: the integrations suite now asserts that an un-allowed course drops out
of /courses while /allocations still reports it, which is exactly what the
consumer sees; the admin suite covers the toggle both ways and a 404 for an
allocation that does not exist.
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
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.
Pathment's mentor course picker came back empty for the Pathment org while all 22 courses sat in its catalog. The integration itself was healthy: credentials verified, the right org resolved, and GET /integrations/v1/courses answered 200 {"courses":[]}. GET /integrations/v1/allocations showed why -- every row was PUBLISHED, unexpired and had 400 free seats, but carried isAllowed: false, which is the one condition listAllocatedCourses filters on.
isAllowed could only be set by the bulk allocation form's single checkbox, which applies to every selected course at once, so one save with it unticked disabled a whole catalog silently. The table still showed those courses "In catalog" with their seats and expiry; the only hint was a quiet "No" in the Allowed column, with no control to change it. The leaderboard flag in the next column already had a per-row toggle. This one did not, so the only way back was re-selecting every course in the bulk form.
Add PATCH /organizations/:orgId/allocations/:courseId/allowed and a per-row toggle in the admin table, mirroring the leaderboard control. The write is audited under organization.allocate, because it grants or withdraws access. Rename the column to Assignable and show a destructive "Not assignable" badge when the flag is off, so a disabled allocation reads as a fault rather than as a neutral status.
Tests: the integrations suite now asserts that an un-allowed course drops out of /courses while /allocations still reports it, which is exactly what the consumer sees; the admin suite covers the toggle both ways and a 404 for an allocation that does not exist.