Merge with dev - #2192
Merged
Merged
Conversation
What was broken
QA re-tested the Design challenge Review section and still saw every reviewer
role (Checkpoint Review, Review, Approval, Checkpoint Screening, Screening)
instead of the single Screener selector requested on the ticket.
Root cause
The first fix gated the simplified Review section on the copilot-only billing
role check (isCopilot && !isAdmin && !isManager). QA and most Topcoder staff
accounts carry the administrator role, so the gate never evaluated to true for
them and the full tabbed configuration kept rendering. The Design track and
Challenge type parts of the gate were correct; only the role restriction was
wrong.
What was changed
The simplified Screener-only Review section now renders for every user editing
a Design Challenge, matching the ticket ("for the entire Review section we need
Screener + dropdown: Select user"). Administrators no longer lose the detailed
configuration: ReviewersField receives a canConfigureFullReview flag and, when
set, renders a "Show advanced review configuration" toggle that expands the
existing Human Review / AI Review / Review Context tabs on demand and collapses
back to the Screener selector. Copilots and managers only see the Screener
selector. The AI-gating "Manual review configuration is required" validation
stays suppressed while the simplified view is showing and re-applies as soon as
an administrator expands the advanced configuration. Challenge Editor
documentation was updated to describe the new behavior.
Any added/updated tests
ChallengeEditorForm.spec now asserts that administrators and managers also get
the simplified Design Challenge review section and that only administrators
receive the advanced-configuration capability. ReviewersField.spec adds cases
for the collapsed-by-default admin view, expanding and collapsing the advanced
configuration, the absence of the toggle for non-admins and non-Design
sections, and the suppressed AI-gating error in the simplified view. The
pre-existing AI-gating assertion in ReviewersField.spec was failing on dev
because the inline message is replaced by the registered form error once the
effect runs; it now asserts the registered reviewers form error instead, so the
suite is green.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
What was broken The Work app in platform-ui had no control for the show_data_dashboard challenge metadata flag, so copilots could not enable the data dashboard graph on a Marathon Match challenge from the challenge editor. MM 166 launched without the dashboard because the flag had to be set manually against challenge-api-v6. Root cause The flag was only ever consumed, never authored. community-app reads the show_data_dashboard metadata entry to decide whether to render the challenge dashboard tab, and challenge-api-v6 stores it as a generic key/value metadata entry, but no editor field ever wrote it. What was changed - Added ShowDashboardField, a "Show Dashboard" checkbox that reads and writes the exact string-valued show_data_dashboard challenge metadata entry, following the existing StockArtsField/RegisteredMemberDownloadField metadata patterns. - Rendered the checkbox in the challenge editor's Advanced Options section only for Marathon Match challenge types. - Defaulted the checkbox to checked for fun challenges that have no saved show_data_dashboard value yet, and persisted that implied value so a save keeps the dashboard enabled. A saved value always wins, so the dashboard can be turned back off. - Seeded show_data_dashboard during Marathon Match creation as true for fun challenges and false otherwise, so the default takes effect as soon as the challenge is set up. - Documented the new field in the ChallengeEditorPage README. No changes were needed in challenge-api-v6 or community-app: challenge metadata is a generic name/value collection and community-app already renders the dashboard tab from this flag. Added/updated tests - New ShowDashboardField.spec.tsx covering the standard Marathon Match default (unchecked, no metadata written), the fun-challenge default (checked and persisted as "true"), saved metadata winning over the fun-challenge default, and toggling persisting exact string booleans. - New parameterized ChallengeEditorForm.spec.tsx case asserting that creating a Marathon Match sends show_data_dashboard "true" for fun challenges and "false" otherwise; the FunChallengeField mock now binds to the form so the fun flag can be toggled in tests. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
PM-5755: Show the simplified Design review section for every role
…r-defaults PM-5755: Preserve hidden Design reviewer defaults
PM-5878: Add Show Dashboard flag to Marathon Match advanced settings
…r-defaults PM-5755: Assign Design reviewers to the copilot
…validation PM-5755: Allow selected copilot through reviewer validation
…stics PM-4621 - tooltip fixes
…stics PM-4621 - handle colors
HOTFIX-PM5755: Fetch timeline-specific reviewer defaults
HOTFIX-PM5755: Resolve phase-name-only reviewer defaults
…board-page PM-5370 campus leaderboard page
…board-page PM-5370 - Minor UI updates for campus leaderboard
…board-page Fixes to campus leaderboard UI
…opilots PM-5954 - show actions in review tab for copilots & reviewers
What was broken The previous PM-5562 follow-up made Development totals include aggregate wins for subtracks whose history had no placement data. QA still found that the profile totals for pops and wleite showed 76 instead of 152 and 2 instead of 36. Root cause Legacy Marathon Match history is partial but contains placement fields. The shared subtrack summary therefore treated those incomplete rows as the source of truth and replaced 76 and 34 valid aggregate wins with zero placement wins. The prior fix only covered histories with no placement fields at all. What was changed Keep an explicit aggregate wins value authoritative for Marathon Match while retaining placement-derived wins for modern tracks. This preserves the earlier Development deduplication and rating-only history fixes. Any added/updated tests Added a regression case modeled on the pops payload, proving that 76 aggregate Marathon Match wins survive a partial placement history with no first-place rows. The existing placement-history and Development aggregation tests remain passing.
PM-4699 Add bubble skill statistics UI with mock data
PM-5562: Preserve aggregate Marathon Match wins
This reverts commit 7d71cb8.
Revert CodeCommit backup mirror
Integrate UI with skill statistics api
…board-page_fixes PM-5939 - campus leaderboard UI
PM-5964 Alignment issue in profile section
What was broken In Work Manager a copilot could select "Limited" for the design submission limit, leave the "Limit count" textbox empty, and still save or autosave the challenge. No error was shown, and the challenge was persisted with limit metadata that declares a limit but carries no number, which no downstream application can enforce. Root cause The submission-limit radio selection and the count are display-only form fields that are serialized into the legacy submissionLimit challenge metadata entry. Nothing in the challenge editor schema validated that entry, so an empty count produced no validation error, formState.isValid stayed true, and both manual save and autosave accepted the incomplete value. What was changed The parsing and serialization of the submissionLimit metadata contract moved into a shared submission-limit utility so the editor field and the validation schema read the same value. The challenge editor schema now rejects limit metadata that declares a limit without a count of at least 1, and reports the message on the visible submissionLimitCount field so the error renders under "Limit count" and in the save footer. Saving, autosaving, and launching are blocked until a count is entered. The rule only applies while the control is editable. The challenge editor publishes an isSubmissionLimitConfigurable flag on the existing yup validation context, which is true only for Design submission settings that have no uploaded contest or checkpoint submissions. That keeps non-Design challenges, and challenges whose limit is already locked by member submissions, saveable. The field revalidates itself after each mode or count change so the error tracks the value that would be saved. Any added/updated tests Added submission-limit utility tests for detecting a limited setting with a missing or zero count and for the contest/checkpoint submission check. Added challenge editor schema tests that a limited setting without a count is rejected on the submissionLimitCount path, that a zero count is rejected, that a valid count and an unlimited setting pass, and that the rule is skipped when the limit is not configurable. Added MaximumSubmissionsField tests that saving is blocked while the count is empty and succeeds once a count is entered. Five of the new tests fail against the unchanged source.
…ate-submissions PM-5727 - UI for duplicate submisisons in work app & review app
PM-5758: require a count when design submissions are limited
…bile-ui Campus leaderboard mobile UI Fixes
…bile-ui PM-5886 - campus leaderboard UI updates
PM-4699 Update mobile view
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Comment on lines
+363
to
+364
| link.getAttribute('href') | ||
| ?.startsWith('https://review.example.test'), |
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
4 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.
Related JIRA Ticket:
https://topcoder.atlassian.net/browse/
What's in this PR?