Activity (Event) Status Filters — What Each Status Means in the Show Admin Grid¶
Audience: Event Operators, Show Admins, Track Chair Admins, Support, QA, Developers Apps/Services: Show Admin (
summit-admin) · summit-api Answers the FAQ: "On the Activities page, what's the difference between Submission Status, Selection Status, Review Status and Published Status — and why does the same word ('Accepted', 'Received') show up in more than one of them?" Verified against code: 2026-06-19 (summit-apimain5a64bc51d· summit-adminmasterda7128bd). File:line citations in the Developer Appendix.
[[../tribal-knowledge/index|Tribal Knowledge]] | [[fnreview-track-chair-guide]] | [[on-site-presentation-upload-process]]
TL;DR¶
- The Activities grid (Show Admin → a Summit → Activities, the "Activity List") exposes four independent status filters: Submission, Selection, Review, and Published.
- They are not four views of one field. They answer four different questions about a Presentation (a CFP submission):
- Submission Status — did the speaker finish submitting it, and is it live?
- Selection Status — where did the track chairs rank it?
- Review Status — one combined "where is it in the whole CFP lifecycle right now" label.
- Published Status — is it on the public schedule?
- The same word means different things in different filters. "Accepted" under Submission just means received + published; "Accepted" under Selection means the track chairs ranked it into a session slot. See §6 The decoder table.
- Most of these statuses are computed live from dates and track-chair lists, not stored flags. The only stored field is the raw submission
status(and theprogressphase behind it) — see §7. - These four filters apply to Presentations only. Non-CFP activity types (Registration, Placeholder Events, Evening Events, etc. — visible in the grid) have no submission/selection/review status.
1. Where you are¶
Show Admin → open a Summit → Activities (URL …/app/summits/:id/events, page titled "Activity List").
The filter panel reads "Search events by all of the following" — every filter you add is AND-ed together, and within a single filter, multiple chips are OR-ed. So Selection Status = Accepted, Rejected AND Published = Published means "ranked accepted-or-rejected by chairs and currently on the public schedule."
You choose which filters appear via the "Select filter criteria" dropdown, and you can save a configuration for reuse — see §8.
2. First, the thing that trips everyone up¶
A Presentation moves through the CFP (Call for Presentations) on two clocks set by its Selection Plan:
- the Submission period — when speakers can create and finish submissions, and
- the Selection period — when track chairs review and rank them.
Almost every status below is derived in real time from where "now" sits against those two periods plus whether the talk landed on a track-chair list. Change the date, and a talk's Review/Selection status changes without anyone editing the record. That's by design — but it's why a talk can read "In Review" one week and "Accepted" the next with no admin action.
3. Submission Status — "did the speaker finish, and is it live?"¶
This is the CFP-completion view. The dropdown offers three values:
| UI label | Internal value | What it means |
|---|---|---|
| Accepted | Accepted |
The submission is complete (status = Received) and the activity is published. |
| Received | Received |
The submission is complete (status = Received) but not yet published. |
| Not Submitted | NonReceived |
The submission was never completed — the raw status is still empty (null). |
⚠️ "Accepted" here ≠ track-chair acceptance. Under Submission Status, "Accepted" is just shorthand for received and published. Track-chair acceptance lives under Selection Status (§4). This is the single most confusing overlap on the page.
The underlying field: a Presentation has a raw status that is null until the speaker completes all CFP phases, at which point it flips to Received. Submission Status filters on that field combined with the published flag. (See §7 for the mechanics.)
4. Selection Status — "where did the track chairs rank it?"¶
This is the track-chair outcome view, driven by the talk's position on the chairs' selection list relative to the number of available slots in its track/category. The dropdown offers:
| UI label | Internal value | What it means |
|---|---|---|
| Pending | pending |
No selection plan yet, or the selection period hasn't started. Chairs haven't begun ranking. |
| Accepted | accepted |
Ranked within the available session slots for its track (order ≤ session_count) — or already published. |
| Rejected | rejected |
Selection period has started/closed, the talk is not on the accepted-or-alternate list, and it isn't published. |
| Alternate | alternate |
Ranked, but beyond the available session slots (order > session_count) — next in line if a slot frees up. |
Behind the scenes the API also computes
selected(on a chair group list at all) and lightning-talk variants (lightning-accepted,lightning-alternate) against the track'slightning_count. The grid dropdown surfaces the four above; the others are used internally and in reporting.
"Accepted vs Alternate" is purely rank vs capacity: the top N talks (where N = the track's session count) are Accepted; everyone ranked below that line is Alternate.
5. Review Status — "one label for the whole lifecycle"¶
If Submission and Selection each answer one question, Review Status rolls the whole CFP journey into a single value. It's computed from the submission/selection periods, the lock-down date, the selection outcome, and the published flag. The dropdown offers six values:
| UI label | Internal value | What it means |
|---|---|---|
| Not Submitted | NotSubmitted |
No selection plan, or the submission was started but never completed. |
| Received | Received |
Submission complete and the submission period is still open — sitting in the queue. |
| In Review | InReview |
Submission complete and track chairs are actively reviewing: either the submission period has closed and selection is open, or a lock-down date is in effect (status frozen for review). |
| Accepted | Accepted |
Selection period closed and the talk ended Accepted or Alternate on the chairs' list. |
| Rejected | Rejected |
Selection period closed, the talk is not Accepted/Alternate, and it isn't published. |
| Published | Published |
The activity is published to the schedule. |
Reading order matters. The engine short-circuits in this priority: In Review (lock-down or active selection) → Published → Accepted/Rejected (only once selection has closed) → otherwise Received. So a published talk reads Published even if chairs also accepted it, and a talk under an active lock-down reads In Review even if it's technically been ranked.
Lock-down date = the Selection Plan's "submission lock-down presentation status date." While
nowis before that date, the talk is pinned to In Review so its status doesn't flicker while chairs deliberate.
6. The decoder — the same word in different filters¶
Because "Accepted" and "Received" each appear in more than one filter with different meanings, use this table to translate:
| Word you see | Under Submission Status | Under Selection Status | Under Review Status |
|---|---|---|---|
| Received | Complete but not published | — | Complete & submission window still open |
| Accepted | Complete and published | Chairs ranked it into a session slot | Selection closed & ended Accepted/Alternate |
| Rejected | — | Not on accepted/alternate list (selection started) | Selection closed & not accepted, not published |
| Published | (folds into "Accepted") | (counts as Accepted) | Activity is on the public schedule |
| Not Submitted | Speaker never finished (status = null) |
— | Same, or no selection plan |
Rule of thumb: - Want "did the speaker finish?" → Submission Status. - Want "what did the chairs decide?" → Selection Status. - Want "one status to triage the whole pipeline" → Review Status. - Want "is it live on the schedule?" → Published Status (§9).
7. The two stored fields: progress and status (and why "revert to draft" is hard)¶
Everything above is derived — except the speaker-submission state, which is two stored fields on the Presentation:
progress tracks how far the speaker got through the CFP wizard tabs:
| Phase constant | Value | Meaning |
|---|---|---|
PHASE_NEW |
0 | Created, nothing saved |
PHASE_SUMMARY |
1 | Summary added, no speakers |
PHASE_UPLOADS |
2 | Has uploads |
PHASE_TAGS |
3 | Has tags |
PHASE_SPEAKERS |
4 | Has summary and speakers |
PHASE_COMPLETE |
5 | Submitted successfully |
status is null until submission finishes. The moment progress reaches PHASE_COMPLETE (5), status is set to Received. That coupling — "progress == PHASE_COMPLETE ⟺ status == Received" — is what powers the Submission Status filter, and it's an invariant the rest of the system assumes.
Why "mark complete / revert to draft" in Show Admin is non-trivial¶
This is the feature currently being scoped (letting admins flip an activity complete/incomplete from the grid). The constraint is the coupling above:
- Marking complete is straightforward: set
progress = 5,status = Received. - Reverting to draft is lossy. Going from "complete" back to "draft" means dropping
progressbelow 5 andstatusback tonull— but the system no longer knows which phase to restore. A talk forced to complete could legitimately belong back atPHASE_SUMMARY,PHASE_SPEAKERS, or anywhere between. There's no stored "phase before completion." - It also overwrites speaker intent. If the speaker genuinely completed the submission, an admin revert makes their finished talk look unfinished again — versus a talk an admin force-completed, where reverting is more defensible.
So a clean revert needs an API-level decision (e.g. persist the pre-completion phase, or distinguish admin-completed from speaker-completed) — it isn't a pure Show Admin UX change. Flag this to the backend team before building the toggle. (Captured from FN dev discussion, June 2026.)
8. Saved filter criteria ("Select filter criteria" / "Save As")¶
The Activities grid lets you save a filter configuration and reload it later:
- Select filter criteria (top dropdown) — load a previously saved set.
- Save As — name the current configuration and choose its visibility:
- Visible to Me — private to you.
- Visible to Everyone — shared with all admins on this show.
- Show Columns — independent of the status filters; controls which columns render in the grid.
Saved criteria are stored per-show under the "Activities" context via the persistent-filter-criteria-api (persistent-filter-criteria-api), so they persist across sessions and (for "Everyone") across users.
9. Published Status — "is it on the public schedule?"¶
A simple toggle, not a multi-select:
| Toggle | Meaning |
|---|---|
| All | No published filter — show everything (the default). |
| Published | Only activities with published = 1 (live on the schedule). |
| Non Published | Only activities with published = 0. |
published is a real boolean flag on the activity. Note it feeds into the other filters too: it's what turns Submission "Received" into "Accepted", and it short-circuits Review Status to "Published."
10. Quick recipes¶
| You want… | Set these filters |
|---|---|
| Talks speakers finished but that aren't live yet | Submission Status = Received |
| Talks the chairs accepted into session slots | Selection Status = Accepted |
| Everything still being reviewed by chairs | Review Status = In Review |
| Accepted talks not yet on the schedule | Selection = Accepted + Published = Non Published |
| Half-finished submissions to chase speakers | Submission Status = Not Submitted (or Review = Not Submitted) |
| Talks chairs ranked just below the cutoff | Selection Status = Alternate |
Developer Appendix¶
All paths relative to each repo root. Verified 2026-06-19 against summit-api main 5a64bc51d and summit-admin master da7128bd.
summit-api (backend — authoritative definitions)¶
Constants — app/Models/Foundation/Summit/Events/Presentations/Presentation.php:
- Selection status constants SelectionStatus_Pending … SelectionStatus_Alternate — lines 111–115
- Phase constants PHASE_NEW (0) … PHASE_COMPLETE (5) — lines 121–147
- const STATUS_RECEIVED = 'Received'; — line 152
- Review status constants + AllowedReviewStatus array — lines 154–168
Derived-status logic — same file:
- getReviewStatus() (the priority short-circuit: In Review → Published → Accepted/Rejected → Received) — lines ~2394–2462
- getSelectionStatus() (rank-vs-session_count / lightning logic) — lines ~953–1004
Filter mappings — app/Repositories/Summit/DoctrineSummitEventRepository.php:
- published → Filter::buildBooleanField('e.published') — line 110
- submission_status switch — Accepted = p.status='Received' AND e.published=1; Received = p.status='Received' AND e.published=0; NonReceived = p.status is null — lines ~111–127
- selection_status switch (pending/selected/accepted/rejected/alternate/lightning-*, keyed on ssp.order vs c.session_count/c.lightning_count) — lines ~214–253
Accepted query params — app/Http/Controllers/Apis/Protected/Summit/Strategies/events/RetrieveSummitEventsStrategy.php: submission_status, selection_status, review_status, published, status, progress.
Review-status SQL function — database/migrations/model/Version20240531145157.php defines the REVIEW_STATUS MySQL function used for filtering/sorting.
summit-admin (frontend — labels & param serialization)¶
Events list page — src/pages/events/summit-event-list-page.js:
- selection_status_ddl (Pending/Accepted/Rejected/Alternate) — line ~1026
- submission_status_ddl (Accepted/Received/Not Submitted → Accepted/Received/NonReceived) — line ~1190
- review_status_ddl (6 values) — line ~1205
- Published toggle (SegmentedControl: All=null / published / non_published) — line ~1421
- Filter widgets rendered at lines ~1415 (selection), ~1890 (submission), ~1905 (review)
Param serialization — src/actions/event-actions.js: builds selection_status==, submission_status==, review_status==, published==1|0; multi-select chips joined with ||.
Labels — src/i18n/en.json: selection_status/submission_status/review_status column headers (lines ~1166–1167); review_status_in_review = "In Review", submission_status_not_submitted = "Not Submitted", etc. (lines ~1206–1214). The Selection Status dropdown labels are hardcoded in the page component, not i18n.
Saved filters — src/components/filters/save-filter-criteria/ and src/components/filters/select-filter-criteria/; context constant CONTEXT_ACTIVITIES and visibility options in src/utils/filter-criteria-constants.js. Backed by persistent-filter-criteria-api.
Last updated: June 19, 2026