PR7a — feat(assessment): Attempt base-record split (Phase 1, additive)

[LWS49]

PR7a — Attempt base-record split (Phase 1)

Stacked on #8507 (pr6d-audit). Phase 1 only: the additive base-record split — no preview feature.

Splits Course::Assessment::Submission into an Attempt base record (keeps the unrenamed course_assessment_submissions table via self.table_name) plus a Submission extension (course_assessment_submission_details), repairs every regression the split touched, and pre-emptively guards base-table reads so no preview row (added in PR7b) can leak into staff-facing counts/stats/reports.

Additive-only — no rename, no data risk. The extension table is new; answers/submission_questions keep submission_id (the base id). Backfill is a gentle 1:1 side-table insert. The unique index (assessment_id, creator_id) stays.

Commits

• Extension table migration + additive split (Attempt base + Submission extension)
• Preview-leak guards on base-table reads (statistics counts/grades/times/answers, grade_summary, discussion from_user, get-help reports) — behavior-preserving today (no previews exist yet)
• Split-regression repairs (data-access surface, authorization rules, grading/ability/live-feedback)

Reviewer guide — submission.rb net changes

The submission.rb diff is large but almost entirely relocation, not deletion: Submission shrank to the course-coupled EXP extension, and the attempt/answers/grading machinery moved to attempt.rb. Nothing below was deleted outright — every removed line either moved to attempt.rb or stayed with a query rewrite.

Moved out to attempt.rb (the base record):

• Workflow state machine (workflow do … end) + the Workflow / WorkflowEventConcern / AnswersConcern includes
• Lifecycle callbacks: after_save :auto_grade_submission, after_save :retrieve_codaveri_feedback, after_create :create_force_submission_job
• Associations: belongs_to :assessment; has_many :submission_questions, :answers (+ the MRQ / text / programming / scribing / forum-post actable answer associations), :question_bundle_assignments, :logs; accepts_nested_attributes_for :answers
• Validations: validate_unique_submission, validate_autograded_no_partial_answer; validates :submitted_at, :workflow_state, :creator, :updater, :assessment
• Methods: auto_grade!, auto_feedback!, questions, assigned_questions, current_answers, current_programming_answers, answer_history, user_get_help_message_counts, evaluated_or_graded_answers, unsubmitting?, submission_view_blocked?, create_force_submission_job; privates auto_grade_submission, retrieve_codaveri_feedback

Stayed on Submission (the EXP / course-coupled slice):

• acts_as_experience_points_record, belongs_to :publisher, validates :last_graded_time
• validate_consistent_user, validate_awarded_attributes
• current_points_awarded, self.grade_summary, self.on_dependent_status_change, the alias_method workflow setters
• calculated :graded_at / :log_count / :grade / :grader_ids — kept, but the subquery now correlates on attempt_id instead of the base id
• scopes — by_user / by_users rewritten as attempt subqueries; confirmed / pending_for_grading now join the base

New (extension wiring the split introduced):

• self.table_name = 'course_assessment_submission_details', belongs_to :attempt
• delegate … to: :attempt — re-exposes the ~30 attempt-level readers/writers so existing submission.<x> call sites keep working unchanged
• self.record_userstamp = false + creator/updater reflection cleanup (stamping belongs to the base)
• Workflow-event wrappers finalise! / publish! / unsubmit! / resubmit_programming! + the after_*_hook seams, with the EXP/email tail (assign_zero_experience_points, send_email_after_publishing, publish_delayed_posts, …) relocated here from WorkflowEventConcern
• assessment_id, ensure_last_graded_time, repoint_attempt_errors_to_base

BEFORE (pre-split)

erDiagram
    COURSE_ASSESSMENT_SUBMISSIONS {
        int id PK
        int assessment_id FK
        string workflow_state
        int creator_id FK
        int updater_id FK
        int publisher_id FK
        datetime published_at
        string session_id
        datetime submitted_at
        datetime last_graded_time
    }
    COURSE_ASSESSMENT_ANSWERS {
        int id PK
        int submission_id FK
    }
    COURSE_ASSESSMENT_SUBMISSION_QUESTIONS {
        int id PK
        int submission_id FK
        int question_id FK
    }
    COURSE_EXPERIENCE_POINTS_RECORDS {
        int id PK
        int course_user_id FK
        int points_awarded
        int draft_points_awarded
        int awarder_id FK
        datetime awarded_at
        int actable_id FK "polymorphic"
        string actable_type "polymorphic"
    }

    COURSE_ASSESSMENT_SUBMISSIONS ||--o{ COURSE_ASSESSMENT_ANSWERS : "has"
    COURSE_ASSESSMENT_SUBMISSIONS ||--o{ COURSE_ASSESSMENT_SUBMISSION_QUESTIONS : "has"
    COURSE_ASSESSMENT_SUBMISSIONS ||--o| COURSE_EXPERIENCE_POINTS_RECORDS : "acts_as_experience_points_record (polymorphic actable)"

Loading

Course::Assessment::Submission is a single model mapped straight to course_assessment_submissions. It directly acts_as_experience_points_record, so the EXP identity columns (course_user_id, points_awarded, draft_points_awarded, awarder_id, awarded_at) live on course_experience_points_records, linked back via a polymorphic actable. There is no course_assessment_submission_details table — it does not exist yet.

AFTER — PR7a (base/extension split)

erDiagram
    COURSE_ASSESSMENT_SUBMISSIONS {
        int id PK
        int assessment_id FK
        string workflow_state
        int creator_id FK
        int updater_id FK
        int publisher_id FK "duplicated, deferred cleanup"
        datetime published_at
        string session_id "duplicated, deferred cleanup"
        datetime submitted_at
        datetime last_graded_time "duplicated, deferred cleanup"
    }
    COURSE_ASSESSMENT_SUBMISSION_DETAILS {
        int id PK
        int attempt_id FK "NEW, UNIQUE"
        int publisher_id FK
        string session_id
        datetime last_graded_time
    }
    COURSE_ASSESSMENT_ANSWERS {
        int id PK
        int submission_id FK "unchanged column name; now points to Attempt base id"
    }
    COURSE_ASSESSMENT_SUBMISSION_QUESTIONS {
        int id PK
        int submission_id FK "unchanged column name; now points to Attempt base id"
        int question_id FK
    }
    COURSE_EXPERIENCE_POINTS_RECORDS {
        int id PK
        int course_user_id FK
        int points_awarded
        int draft_points_awarded
        int awarder_id FK
        datetime awarded_at
        int actable_id FK "polymorphic"
        string actable_type "polymorphic"
    }

    COURSE_ASSESSMENT_SUBMISSIONS ||--o{ COURSE_ASSESSMENT_ANSWERS : "has"
    COURSE_ASSESSMENT_SUBMISSIONS ||--o{ COURSE_ASSESSMENT_SUBMISSION_QUESTIONS : "has"
    COURSE_ASSESSMENT_SUBMISSIONS ||--o| COURSE_ASSESSMENT_SUBMISSION_DETAILS : "0..1 (absent ⇒ preview) — NEW relationship"
    COURSE_ASSESSMENT_SUBMISSION_DETAILS ||--o| COURSE_EXPERIENCE_POINTS_RECORDS : "acts_as_experience_points_record moved here (polymorphic actable)"

Loading

What's new in this diagram: the COURSE_ASSESSMENT_SUBMISSION_DETAILS box (a brand-new table) and the 0..1 (absent ⇒ preview) relationship line connecting it to the base table — that single optional edge is the entire feature. Everything else (answers, submission_questions, their FK columns) is structurally untouched; only what the FK conceptually points to has shifted from "the one and only submission row" to "the Attempt base row, which may or may not have a submission extension."

course_assessment_submissions is now Course::Assessment::Attempt — the base record: workflow_state, answers, grading, and the unique (assessment_id, creator_id) index. course_assessment_submission_details is the new Course::Assessment::Submission extension, has_one-linked via attempt_id (unique, so at most one extension row per base row). The extension is now what acts_as_experience_points_record.

The base table still physically carries publisher_id, session_id, and last_graded_time alongside the new extension's copies of the same names — this is intentional duplication left over from the additive, no-rename migration strategy. A later deferred-cleanup PR drops the base table's copies once all callers read from the extension. This is noted here in prose rather than cluttering the diagram above.

ID identity — how old data stays compatible

The base table was never renamed or re-keyed, so every historical submission row keeps its id. The backfill inserts one extension row per base row with attempt_id = base.id. The result:

Object	id it exposes	Equals the legacy/historical submission id?
Attempt (base, course_assessment_submissions)	attempt.id	✅ same row, same id, never re-keyed
Submission (extension, course_assessment_submission_details)	submission.id	❌ brand-new serial, nothing legacy references it
Submission (extension)	submission.attempt_id	✅ = the base/historical id

So submission.attempt_id == attempt.id == the pre-split submission's original id. Every child FK (answers.submission_id, submission_questions.submission_id, logs.submission_id, …) still references that base id, unchanged — which is why old data stays valid.

Consequential rule for the whole split: whenever code holds a Submission (extension) object and must match a child's submission_id, use .attempt_id, not .id (e.g. the live_feedback/thread_concern and koditsu submissions_concern fixes in PR7a). .id is the extension's own serial and matches nothing on the children.