Conversation
What was broken Checkpoint attempts consumed final-submission slots, the regular My Submissions page could navigate past a reached limit, and concurrent client checks could create duplicate attempts. Entry-point checks also relied on a partial challenge submission page. Root cause Submission-limit checks counted every submission phase together, were missing from the regular submission-management route, and started the submit pending state only after an asynchronous lookup. What was changed Centralized active submission-type handling, counted checkpoint and contest attempts independently, and bypassed concept limits for final fixes and non-Design tracks. Added complete member-and-type history checks to the challenge header, regular My Submissions route, and upload boundary, with synchronous in-flight guards and fail-closed lookup handling. Any added/updated tests Added and updated utility, service, header, challenge-detail, Submission Management, and upload tests covering phase separation, full-history checks, reached and below-limit navigation, concurrent attempts, lookup failures, final fixes, unlimited challenges, and Development challenges.
PM-5758: enforce design submission limits end to end
fixes PM-5914 -> dev
Fix profile links to bypass redirects
What was broken On the Opportunities page, the "All" filter (and the count shown next to it) omitted every active challenge whose open phase was not Submission. Challenges sitting in Review, AI Review, Approval, Screening, Iterative Review, etc. were missing from the list, so a challenge that was clearly visible under "My Challenges" produced "No Live Challenges found" under "All". Root cause The All-bucket request and the total-count request in src/shared/actions/challenge-listing/index.js sent currentPhaseName=Submission (added under PM-5488 to keep not-yet-started challenges out of the live list). The challenge API matches currentPhaseName against a single phase name, so the filter also dropped every active challenge that had already moved past submission. The same over-restriction was removed from "My Challenges" earlier for the same reason, which is why the challenge appeared there but not in "All". What was changed Replaced currentPhaseName=Submission with startDateEnd=<now> in getAllChallengesDone and getTotalChallengesCountDone. The All bucket now requests every started ACTIVE challenge, matching the bucket's original definition (started + Active) and the phase-agnostic My Challenges request, while still excluding challenges whose start date is in the future. Any added/updated tests Updated __tests__/shared/actions/challenge-listing/index.js so the All and total-count regression tests assert the ACTIVE + startDateEnd filter and explicitly assert that no currentPhaseName constraint is sent. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
What was broken
Private (group restricted) challenges were listed in the "Open for Review"
bucket of the community app Opportunities page for anonymous visitors and for
members who are not part of the challenge group. After the review API started
enforcing group visibility, the opposite problem appeared: the opportunities of
group challenges were no longer visible to admins or to members of those
groups either.
Root cause
The community app called the v6 review opportunity endpoints without an
Authorization header. GET /v6/review-opportunities (and
GET /v6/review-opportunities/{id}) evaluate challenge group access against the
caller, so every community app request was treated as anonymous. An anonymous
caller must only receive opportunities of public challenges, which is why the
listing could never show group challenges to the members entitled to see them,
while older API builds that did not filter at all exposed them to everybody.
What was changed
- services/reviewOpportunities: added a shared getRequestOptions helper that
attaches "Authorization: Bearer <tokenV3>" when a token is available, and
used it for both the review opportunity listing and the details requests.
- actions/challenge-listing: getReviewOpportunitiesDone now accepts tokenV3 and
forwards it to the service.
- containers/challenge-listing/Listing: the load-more handler and the
mapDispatchToProps binding pass the logged in user's tokenV3.
- actions/page/review-opportunity-details: getDetailsDone forwards the tokenV3
that the details container was already dispatching.
No API change was required: review-api-v6 already filters challenge ids by
challenge groups (and bypasses that filter for admin and M2M callers), which
was verified against api.topcoder-dev.com where a grouped challenge's OPEN
review opportunity is returned for an M2M caller and withheld from an
anonymous caller.
Any added/updated tests
- __tests__/shared/services/reviewOpportunities.js: new "auth token
forwarding" suite asserting the Authorization header is sent for the listing
and details requests when a token is present, and omitted for anonymous
listing requests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
PM-5895: send auth token when loading review opportunities
PM-5897: Show later-phase challenges under the All filter
What was broken Group-restricted review opportunities remained missing for admins and eligible group members even after the earlier fix began forwarding bearer tokens. A restricted result already loaded for one caller could also remain cached after the caller logged out. Root cause Community app authentication is populated asynchronously. The Open for Review bucket could therefore complete its first request anonymously before tokenV3 arrived. The review-opportunity rows and all-loaded pagination flag were never invalidated when authentication changed, so the authenticated request was not made and the anonymous result set stayed on screen. What was changed - Added a focused action and reducer path that clears only review-opportunity rows, pagination, loading, and completion state. - Clear that caller-specific cache whenever tokenV3 changes. - Immediately reload page zero with the current token when Open for Review is active; inactive buckets remain lazy-loaded. Any added/updated tests - Added lifecycle coverage for delayed authentication, logout, and auth changes while another bucket is active. - Added reducer coverage proving the review-opportunity cache resets without changing other challenge buckets. - Verified the full test suite, lint, and production build.
PM-5895: refresh review opportunities after auth changes
… is open What was broken In Design challenges the submitter could still delete a submission after the phase that created it had ended. In particular a checkpoint submission stayed deletable for the whole Submission phase, so it could be removed after it had already been screened and scored in Checkpoint Screening / Checkpoint Review. Root cause SubmissionsTable computed the delete permission from a single "submissionPhaseStartDate" prop, which was the start date of *any* open Submission or Checkpoint Submission phase, and compared it against subObject.submissionDate - a field that member submissions do not carry (they expose "created"). The comparison therefore resolved to "now is after the open phase start", i.e. the delete button was enabled for every submission whenever any submission phase was open, regardless of which phase actually produced the submission. What was changed - Added belongsToActiveSubmissionPhase() to utils/challenge-detail/submission-limit, which reuses the existing getActiveSubmissionType() phase precedence to decide whether a submission was created by the currently open submission phase. - SubmissionsTable now derives allowDelete from the submission's own type against the open phase, so checkpoint submissions stop being deletable when the Checkpoint Submission phase closes, and nothing is deletable once every submission phase is closed. - Removed the now-unused submissionPhaseStartDate prop from the submission management container and components. Any added/updated tests - __tests__/shared/utils/challenge-detail/submission-limit.test.js: new belongsToActiveSubmissionPhase suite covering checkpoint deletion during the checkpoint phase, checkpoint deletion blocked once the Submission phase opens, everything blocked during screening/review, and missing submission/phase input. - Updated the SubmissionsTable shallow snapshot for the now-boolean allowDelete prop. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
PM-5961: only allow deleting submissions while their submission phase is open
…-20260826 chore: remove retired enterprise communities
Route migrated Contentful spaces through Payload CMS
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
2 participants
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.
No description provided.