Aeries Login

Features in this preview 13

Assign, escalate and dispute issuesupdated 2026-10-14

Issue detail has one side panel: Assignee with Change, Due date and one Save, then Acknowledge, Resolve and Ask Aeries Assistant. Acknowledge and Resolve apply one required note to every currently open record of the issue after a preview; they are not a separate issue state. Acknowledge means reviewed and left as-is on purpose: the dialog says so before you save, and acknowledged records leave the Open count for their own Acknowledged tab, never shown as Resolved. Existing assignment and permission behavior remains. Assign an issue to a staff member with a due date and check the deadline on the dashboard. The My notifications box at the bottom right has been removed; there is no notification inbox on screen for now. Open the Action history tab beside Affected records, refresh it and load older entries; try switching tabs with the keyboard and reopening a copied history link. With history loaded, the three-dot menu at the top right of Action history exports every action you can see that matches the search, across all pages, as CSV. Grouping eight separate issues into one assignment, escalation to a coordinator and issue comments are not available yet.

Open the starting page →

Walkthrough unavailable for this build

Jira

SIS-98 Assign, escalate and dispute issues

Test as

Hosted admin (district-wide)
Staff user
Hosted admin (district-wide)

Build timeline

Build notes are not collected yet for this build.

QA walkthrough

Check Pete/Lester’s eight-distinct-issues batch acceptance before calling story 2.3 Working.Expect: Partial: assignment currently accepts one issue per call, and the feed groups by issue. Eight records within one issue consolidate; eight distinct issues in one batch do not. The acceptance probe records expected one notice / actual eight.
Inspect the single Assignment & next steps panel at 1440px and 390px. Use Tab through Change, Due date, Save, Acknowledge, Resolve and Ask Aeries Assistant.Expect: One assignment editor with one Save, then Acknowledge, Resolve and (where the Assistant is enabled for this preview) Ask Aeries Assistant. There is no Reassign to Someone Else, Extend Due Date, Escalate to Coordinator or Comments. Assignee help directs unavailable-assignee recovery to Change. Controls fit without horizontal clipping.
In the isolated demo database only, open an issue that has open records and at least one record already acknowledged or resolved. Click Acknowledge in the side panel.Expect: A dialog titled with the number of open records (for example Acknowledge 14 open records) opens with the cursor in the note. Above the note it says what Acknowledge means: you reviewed these records and are leaving them as they are on purpose; they leave the Open count and the must-fix work list, move to the Acknowledged tab with your note, and are not marked Resolved. It also says already deferred, acknowledged or resolved records are not changed and that your name and the time will be recorded. Preview is disabled until a note is typed. Escape or Cancel closes it, returns focus to the button and writes nothing.
Type a note and click Preview, then click the Acknowledge N records button. Repeat with Resolve on another issue.Expect: Preview states how many open records will change and lists any that cannot; nothing is written. Editing the note requires a new preview. Applying reports N of M records updated and names any that failed and remain open; after Acknowledge it adds that updated records are on the Acknowledged tab and no longer counted as open. The Open and Acknowledged tab counts (after Acknowledge) or Open and Resolved counts (after Resolve), the record badges and the Action history tab reload and show your name, the time and the note on each changed record; records that were already acknowledged, deferred or resolved keep their earlier history.
On an issue whose only remaining records are acknowledged (isolated demo database), read the Open tab, the side panel and the dashboard row.Expect: Open reads 0 and says every record of this issue is acknowledged; the side panel says there are no open records to acknowledge or resolve; the Acknowledged tab holds every record with its note. The dashboard row shows 0 open and lists the acknowledged count separately; no acknowledged record is labelled Resolved.
Open an issue with no open records. Repeat the Acknowledge flow at a 390px window.Expect: With no open records, Acknowledge and Resolve are disabled with a short explanation. At 390px the dialog fits the screen, keeps focus inside and nothing is cut off.
Open Issue Detail and inspect Due date (optional) in the Assign sidebar card.Expect: The field is about 34px high, like the other sidebar controls, and about 160px wide rather than spanning the card. The calendar control and complete date remain visible.
Open an unassigned issue. In the assign card, search for 'test' in the assignee picker, pick it and set a due date.Expect: The picker suggests real lab users. The selected user shows as a chip.
Click Save.Expect: The issue header shows the new assignee and due date as soon as the save answers, before the page re-reads the issue (throttle the network to see it). Record rows do not repeat it; a record whose assignee or due date differs from the header says so in its expanded detail. A conflict (“Already assigned to …”) or any failed save leaves the header unchanged. If you save twice quickly, the header ends on the second person, never back on the first.
In an isolated preview on the reviewed build, assign eight scratch records to an enrolled synthetic recipient with a due date today.Expect: Assignment saves. Open the dashboard and an issue, in the full-screen and embedded views: there is no My notifications box at the bottom right, no empty space where it was, and the page beneath that corner can be clicked.
Return to the coordinator dashboard and inspect the assignment’s deadline.Expect: Inside the configured reminder window the issue says At risk · Due soon. A lapsed deadline says Action needed with a link to reassign or extend the date.
On the dashboard, click an assigned overdue issue’s avatar. Go back and click its due date. Repeat with Tab then Enter, with Space, on an issue with no assignee, and by reloading the issue page with ?action=reassign or ?action=extend still in the address. Then click the row’s arrow.Expect: The avatar opens the issue with the assignee search box open and focused in the side panel; it is still open after the page finishes loading. The due date opens the issue with the Due date field focused and the saved assignee unchanged. Keyboard and reload do the same. The arrow opens the issue with nothing opened.
Clear the date and click Save again with the same assignee.Expect: The assignment saves without a deadline; the field stays empty and no required-date error appears.
Click Change beside the assignee, then click into Due date.Expect: Change opens the assignee search box and puts the cursor in it. The Due date field is edited in place. Nothing is written until Save.
Acknowledge one record (see Record actions), then click View Rule History.Expect: The history table lists the rule's creation and the new events, with actor names (not IDs).
Close the history, expand a record and click View Data.Expect: The student's record opens in Aeries.
As admin, build and save a custom rule that flags at least one record (see Rule builder). Refresh results.Expect: The rule's issue is on the dashboard.
Open that issue and dispute a record (Dispute, enter a reason, Submit Dispute).Expect: The saved confirmation says the dispute was sent to the rule's author (the account that saved the rule).
Open a system rule's issue (an AERIES0xx rule) and dispute one record.Expect: The saved confirmation says it was sent to 'Aeries Product Team'. There is no preview for one record, so this does dispute that record.
Do the same on a CALPADS rule's issue (after a practice run).Expect: The saved confirmation says it was sent to 'Aeries State Reporting Team (CALPADS)'.
Deactivate your scratch rule.Expect: The lab is clean again.
Open a rule detail and select the Action History tab, the third tab after Open and Resolved. After a separately authorized existing action is recorded, click Refresh history.Expect: The new event appears first with actor, timestamp, record/school pointer, factual action and stored audit code. No action or mutation control appears in history.
Use Load more history, then compare with a staff account restricted to other schools or without the rule group security-area Read right.Expect: Older pages remain stable while new events arrive. Denied records, deleted student pointers and counts of hidden records are absent. Empty and failed reads show different messages; retry preserves already visible history.
Open an issue whose Action History tab shows 25+ (more than one page of recorded actions). Without loading more, open the three-dot menu at the top right of the tab (it reads “Action history actions” to a screen reader) and choose Export to CSV (.csv).Expect: The menu sits where the records menu sits on Open and Resolved and has one option, Export to CSV (.csv). While the file is prepared the button shows it is busy, the item is disabled and “Preparing your export, this may take a while” shows. A .csv file named data-validations-issue-<id>-action-history-<time>.csv downloads and the line under the tabs says how many actions it holds: every recorded action you can see, not only the 25 loaded. An issue with no recorded actions you can see shows no three-dot menu on this tab.
Open the file in a spreadsheet and compare it with the tab after clicking Load more history until it stops. Then type an actor name, “record #<id>” or an action such as Dispute in the search box and export again.Expect: Columns: Audit ID, Who, When (yyyy-mm-dd hh:mm:ss, blank when the time was not recorded), Record ID, School, Action and Audit code. Rows are newest recorded first, the first and last match the tab, and each Audit ID appears once. No notes, student names or field values are included. With a search, the file holds every action matching it, including ones never loaded on screen; with a search that matches nothing it holds column headings only and says so. A name beginning with = + - or @ shows a leading apostrophe.
Repeat the export with a staff account restricted to other schools or without the rule group’s security-area Read right, and while another two exports are still being prepared.Expect: The restricted account’s file holds only the actions its Action History tab shows (none for a school it cannot see). A third concurrent export says you already have exports being prepared and offers Try again; nothing partial is saved. Exporting does not change any record or history.
Open an issue that has open, acknowledged and resolved records. Read the four tabs, Open, Acknowledged, Resolved and Action History, and open each one at 1440px and 390px. Type part of a student name or ID in the search box on each tab.Expect: Open is the default tab. Its count is the number of records whose status is Open, the same as the issue's open count on the dashboard and in the Acknowledge and Resolve dialogs. It also lists deferred and disputed records, which it does not count (a note beside Select all names them), and never lists acknowledged or resolved records. Acknowledged lists only acknowledged records, explains above them that they were reviewed and left as they are on purpose with a required note and are not counted as open or must-fix and not resolved, and offers no Select all. Resolved lists only resolved and auto-resolved records and offers no Select all. Action History lists recorded actions newest first with who and when. Open, Acknowledged and Resolved show the count for the whole issue, including pages not loaded yet; Action History shows how many actions have been read once it is opened, with a plus sign while more pages remain. Search narrows the rows already loaded on the tab you are on without changing the counts. At 1440px the tabs fit on one line; at 390px they wrap to a second line with every tab fully visible, and the page never scrolls sideways.
Switch between the four tabs with click, Left/Right arrows, Home and End. Refresh on Action History, then switch to Open and use browser Back and Forward. Open a copied Resolved or Action History URL in a new tab. Resolve one open record, then open Resolved.Expect: The selected tab stays in the URL (Open has none) and survives refresh, Back, Forward and a shared link. Export to CSV (.csv) and View Rule History are offered on Open, Acknowledged and Resolved, not on Action History. Switching tabs keeps loaded rows, selection and expanded record actions; each record tab keeps loading more rows automatically as its end scrolls into view, with the shared three-dot loader. The resolved record leaves Open and appears on Resolved, and both counts change. History loads on opening and retains existing read-only rights and empty/error states.
Review the side panel with Pete and Jesse. Feedback review tag: Want Pete's take.Expect: Escalate to Coordinator and Comments are not shown until Pete decides their routing; nothing was removed from the server. Keep the review tag and decision in the feedback trail.

Inspect and resolve issue recordsupdated 2026-10-14

Open an issue behind a centered three-dot loader, then inspect its first affected-record page after the summary and records are ready, with student names when available. Each record row is one compact line pair: a one-line title (student name, Student #id when no name is available, or the record key) over a byline with the problem, student ID and age (on narrow screens the problem gets its own line). View Data and any differing assignment appear once a row is expanded. Use the ellipsis beside the tabs for CSV export of the tab and search on screen, and for rule history. Expand records, save a Resolve, Acknowledge or Dispute with one Confirm, and scroll for later pages without hiding loaded rows.

Open the starting page →

Walkthrough unavailable for this build

Jira

SIS-96 Inspect and resolve issue records

Test as

Hosted admin (district-wide)

Build timeline

Build notes are not collected yet for this build.

QA walkthrough

Open issues/4 at a desktop width of 1440px; throttle the requests and try different completion orders for the summary, first record page and display names.Expect: One page-wide centered three-dot loader stays visible until summary and first-page records settle; display names have a two-second wait limit before using pointer-only labels, and a slower (not failed) lookup still replaces those labels with names in place when it answers; summary, assignment and decorated records appear together with one quick fade. Reduced-motion users get no animation. Later pages keep existing records visible and do not gate the whole dataset.
Open an issue from the dashboard. Inspect its header and Assign card.Expect: Open full screen and What’s new sit on the breadcrumb row, right-aligned (full screen shows What’s new only). The title and severity/OVERDUE share the next row. The byline below starts with the issue number (for example Issue #4), then First flagged, assignee and due date, on one line at desktop width and without repeating the title code. The due-date field has normal input height and date-sized width.
Inspect collapsed record rows at 1440px and 390px, including a long name or problem text. Then open Affected records actions and use Up/Down, Escape and Tab.Expect: The title is one line and never wraps: the student name, Student #id when no name is available, or Record #key for a record with no student. The byline shows the problem, the student ID (when the title is a name) and Open N days or Flagged N days ago; long text ends in an ellipsis and its full text is in the hover title, the row's accessible name and, in full and wrapping, at the top of the expanded detail. Checkbox and status badge are vertically centered. No open icon and no Unassigned label appear on a collapsed row. The right-side ellipsis exposes Export to CSV (.csv) and View Rule History, with no Excel choice; menu dismissal restores focus. Affected records and Action history stay on their existing row.
On an issue with more than 50 affected records, type part of a student ID in the search, open Affected records actions and choose Export to CSV (.csv). Switch to the Resolved tab and choose Export to CSV (.csv) again. Then search for text no record contains and export again.Expect: The CSV holds every record on the Open tab (open, deferred and disputed, never acknowledged) matching the search, including records not yet loaded on screen, with Record ID, School, Student ID, Student, Key 1, Key 2, Description, Status, Reason / note, Status date, Assignee, Due date, First flagged and Age (days). The Resolved tab’s CSV has the same columns for the resolved records only (from the Acknowledged tab, an export holds only acknowledged records). Student names appear only where you may read the student's school. Text beginning with = + - or @ shows a leading apostrophe. A line under the tabs names each file and its record count; the empty export holds column headings only and says no records match. Exports change no record. There is no row limit: while a file is prepared the menu button is busy, the export item is disabled and a spinner line reads “Preparing your export, this may take a while”; a large export may take minutes and cannot be started twice. If an export fails or is stopped, a red message appears under the tabs, nothing is downloaded, and the message has one Try again button, which repeats the same export, and a Dismiss button. A server timeout is reported as a timeout (“The CSV export took longer than the server allows and was stopped”), and a dropped connection or a file cut off before its end as “interrupted before it finished”. A partly received file is never saved.
Click anywhere on a collapsed record row, including its padding, or focus the summary and press Enter/Space. Also use its checkbox, then View Data inside the expanded detail.Expect: The pointer and hover indicate a clickable row. Click/Enter/Space toggle details and aria-expanded. Checkbox selects independently. View Data is a button shown only in the expanded detail; it opens the same authorized student/school context in a new tab and leaves the row expanded. When a record's assignee or due date differs from the issue header, the expanded detail says so (for example Unassigned). The magic wand opens the Assistant for that record without expanding the row. In the expanded detail the full record text and any differing assignment sit on the left, and View Data, Rescan, Resolve, Acknowledge, Dispute or Reopen sit on the right of the same row; at 390px the buttons wrap below the text and stay right-aligned. This is inside the record, not the page header.
Open an issue with more than 50 records. Scroll toward the bottom, then focus the loading sentinel using the keyboard.Expect: Each next page loads automatically once. Loading is announced without hiding existing rows. No Load more button remains. The final page announces All N records loaded; a failed page offers Retry.
Select all on an issue with 260 open records while only the first 50 rows are loaded. Scroll to load another page, then uncheck one open row.Expect: The label reads "Select all 260 records marked Open": it counts only records whose status is Open, the same number as the Open tab's count. The Open tab also lists deferred and disputed records without counting them; when it does, a short note beside the checkbox names them (for example Open 44, "Select all 44 records marked Open", "2 disputed records are not included"); the note is absent when every row on the tab is marked Open, and it drops below the checkbox at 390px. The selected count uses 260, newly loaded open rows stay selected, resolved/auto-resolved rows keep a disabled, unchecked checkbox so their text aligns with open rows. Unchecking one shows 259 and retains the full server scope.
In the isolated demo fixture only, preview and confirm a full-set bulk action. Inspect the request payload and the final record beyond the loaded pages.Expect: The request sends allMatchingOpen, exclusions and expectedCount (the number shown in the label), never a client list of all selected IDs. Preview writes nothing; confirm applies to the full server set within your own school/group scope. If the matching set or its size changed, or the preview expired, nothing is written and a new preview is required.
Sign in to one school where the same rule also has findings at other schools. Select all, enter a note, then Preview and Confirm.Expect: The preview, the Confirm label and the result never exceed the number in "Select all N records marked Open". Records at the other schools keep their status and gain no Resolution Status entry.
Open the same issue in two tabs. Resolve one open record in the first tab. In the second tab, without reloading, Select all and Preview.Expect: "This selection matches N records, but M were shown. Nothing was changed." appears and Confirm is not offered; no record changes until you reload and select again.
Type a search that matches only some open records, then tick Select all and Preview.Expect: The label reads "Select all N shown records marked Open" and the request lists exactly those record IDs with expectedCount N; records hidden by the search are not included.
Expand an open record and click Resolve. Before typing, look at the row and the panel.Expect: There is no Preview button. The cursor is in the Reason box. The row shows a dashed "Not saved" tag beside its Open badge and the panel says "Not saved yet". Confirm is disabled until the reason has text; spaces alone do not enable it. The panel's bottom row has the save state on the left and Cancel then Confirm at the right, as in the other dialogs; Tab from the Reason box reaches Cancel, then Confirm. Cancel closes the panel and saves nothing.
Enter a reason and click Confirm once.Expect: The button reads Saving and cannot be pressed again; one save request is sent. The "Not saved" tag goes away only when the save succeeds. The record's badge changes to resolved. A confirmation ("Record resolved. It is now on the Resolved tab, and your reason is in its Resolution Status.") is scrolled into view above the tabs and stays until dismissed; it is the only confirmation on the page and is still shown on the Resolved tab. On the Resolved tab, its Resolution Status shows your name, the time and your reason.
On another record, click Acknowledge, read the panel, add a note and click Confirm.Expect: Before you type, the panel says Acknowledge means you reviewed this record and are leaving it as it is on purpose; it leaves the Open count and the must-fix work list, moves to the Acknowledged tab with your note, and is not marked Resolved. After Confirm, "Record acknowledged. It is now on the Acknowledged tab, not counted as open and not resolved, and your note is in its Resolution Status." appears once, above the tabs, scrolled into view, and stays until dismissed; the row repeats no confirmation. The record leaves the Open tab (its count drops by one) and appears on the Acknowledged tab (its count rises by one) with the Acknowledged badge, never Resolved, and its Resolution Status gains your name, the time and the note. A blank note is refused before anything is looked up.
On another record, click Dispute, enter a reason and click Submit Dispute.Expect: "Record disputed and sent to <owner>. Your reason is in its Resolution Status." appears once, above the tabs, scrolled into view; the row repeats no confirmation. The record shows disputed and its Resolution Status shows your reason. A save the server refuses keeps the panel open with "Not saved." and the reason, shows no confirmation, and the row still says "Not saved". If the server does not answer at all (for example the network drops), the panel does not say "Not saved": it says the save could not be confirmed and to refresh and check the record's status and Resolution Status before trying again, and the row says "Save not confirmed".
Click Rescan This Record.Expect: It rescans straight away (no preview) and reports whether the record still flags. It works on records your issue list shows; another school's record is refused like a missing one.
Signed in as a one-school lab user, use the API on a record ID that belongs to another school: resolve, rescan, assign, assistant bulk-acknowledge, and a batch that includes it.Expect: Resolve, rescan, assign and assistant acknowledge answer 404 and the batch answers 400 invalid_selection. None of them reads the record through its rule or changes it, at any school.
On an auto-resolved record, click Reopen (not a rule dispute) and type only spaces in the comment, then enter a real comment and click Confirm. Watch the confirmation for 10 seconds.Expect: Confirm stays disabled while the comment is only spaces. After Confirm the record is open again and the page says "Record reopened. It is Open again, and the reopening is recorded in Action History." with the text vertically centered beside its ×; that confirmation clears itself after 10 seconds (the × clears it sooner, and a new confirmation replaces it and starts its own time). Resolve, Acknowledge and Dispute confirmations, and every error, stay until dismissed. The Action History tab lists it as Reopening recorded, and the record's Resolution Status shows a Reopened step with your name and comment.
Reopen a record you resolved by hand (Resolved tab), one you acknowledged and one you disputed (Open tab): expand the row, click Reopen, enter a comment and click Confirm. Reload the page.Expect: Each record is Open again and counted as open. Its Resolution Status keeps the earlier step (Resolved-manual, Acknowledged or Disputed, with its reason) and adds Reopened with your comment. Open and deferred records have no Reopen button. Whether reopening a disputed record also clears the dispute is not decided yet: the dispute and its reason stay in the history.
Repeat acknowledge and resolve at a phone-sized window.Expect: The same results and badges; nothing is cut off.
Open an issue with three or more open records. Tick two record checkboxes.Expect: The batch bar appears and says 2 selected.
Click Acknowledge in the batch bar, enter a note and click Preview.Expect: The panel first says what Acknowledge means (reviewed and left as they are on purpose; out of the Open count and the must-fix work list; on the Acknowledged tab; not marked Resolved). One batch request carries exactly the two ticked record IDs and expectedCount 2; no per-record requests are sent. The preview lists the outcome per record. Nothing is written yet.
Click Confirm, then Done.Expect: "2 of 2 records updated." Both records move to the Acknowledged tab with the Acknowledged badge, each with its own Resolution Status entry. A record that could not change is listed by name and counted (for example "1 of 2 records updated.").
Tick a third record and batch-Dispute it (a batch of one).Expect: It shows disputed.
On the issue, open Affected records actions and choose Export to CSV (.csv).Expect: The .csv has every record of the issue on the selected tab.
On the dashboard, set a severity or status filter, open the three-dot menu at the end of the filters, then choose Export to CSV.Expect: The .csv holds only the filtered issues, including any beyond those loaded on screen.
On this preview, use a synthetic student with a confirmed builder rule checking Next school equals zero. Open the issue, expand the record row, and activate View Data with Enter.Expect: The same student, school and resolved year open. Next school is visibly marked with text, scrolled into view and focused; a screen reader can read the validation indication.
Use a two-operand supported builder rule, then repeat with an omitted field, a denied record, stale mapping or unsupported rule/page.Expect: All available operands are marked and the first receives focus. Denied data is never shown. Unknown mappings show no guessed field or fallback message; the student validation banner remains visible.
On this preview, use a synthetic issue with more than 50 affected records. Export it, then export the dashboard unfiltered and with search/status/severity filters. Repeat with a school user lacking another group’s read access and with STU read withheld.Expect: The issue file contains the complete authorized list, including records not loaded on screen. The dashboard CSV excludes unauthorized schools/groups; the issue CSV holds only records you may see. Student names are blank without STU read. Exports do not change record states; there is no 10,000-row limit: a large export shows “Preparing your export, this may take a while” until the file arrives, and a failed export saves no partial file.
On this preview, search or filter the Issues list, open an issue, expand a synthetic student record, then use View Data.Expect: The same student, school and year open. The breadcrumb reads Data Validations (beta) > Issues > the rule-name breadcrumb (or Rule details if the name is unavailable).
Reload the student page. Use Tab and Enter on the rule-name breadcrumb (or Rule details if the name is unavailable) to return to the issue, then activate the Issues breadcrumb.Expect: The originating issue opens and its loaded record row receives focus. The Issues list retains the search, filters and sort. On a narrow screen, the immediate parent breadcrumb remains available.
Use Try the new version on classic Demographics, or open modern Demographics directly with student/school/year context.Expect: The same student, school and year are retained. When an originating issue is supplied, its rule-name breadcrumb (or Rule details if the name is unavailable) returns there. A direct student link uses the Issues breadcrumb to reach the list without relying on browser history.
On this preview, expand records and use View Data from records with a known failing field and from records with an unknown mapping. Return through the breadcrumbs, then scroll the affected-record list to load another page.Expect: Known fields have a short muted label; unknown rows show no fallback. The student validation banner remains, available fields keep highlight/scroll/focus, and unknown mappings show no cannot-identify message. Paging shows a brief inline loading status only while fetching; no idle blank block remains.
Repeat with an empty record page, failed summary or records read, a denied display-name lookup, stalled display-name response and denied student access. Release the stalled names after the page reveals.Expect: Loading ends on settled success or error; errors remain specific to their requests. A stalled names read is cancelled after two seconds; pointer-only rows appear together once records and summary arrive, and late names do not re-render or flash the page. Withheld student names stay withheld and destination access checks still refuse denied data. Export includes the full authorized dataset, beyond the first page.
Rescan a language rule (SIS-321): open the issue for Invalid Reporting Language (AERIES-025) on demo data, expand an open record and select Rescan This Record.Expect: The rescan answers: the record is either resolved or reported as still flagged. It no longer fails with an unable-to-rescan message. The same holds for the other language rules AERIES-026 to AERIES-030.
SIS-329, in the isolated test preview only: on a scratch rule with three records, Resolve two and Acknowledge one. Open the issue, then go back to the dashboard.Expect: The issue shows RESOLVED on the dashboard and on its page. The header lists "Resolved 2 / Acknowledged 1"; Acknowledged is never counted or labelled as Resolved. The Open tab counts 0, Acknowledged 1 and Resolved 2. The dashboard row reads "0 open records" followed on the same line by "Resolved 2 / Acknowledged 1", and the issue is listed under Status Closed, not Open. Action History still lists both actions with their notes.
On a scratch rule with three records, Resolve two and Dispute one.Expect: The issue does not show RESOLVED: a pending dispute is never presented as fixed. The disputed row stays listed on the Open tab while the tab counts 0, because only records marked Open are counted. The header lists "Disputed 1 / Resolved 2" and Status Open on the dashboard lists the issue. (A Deferred record keeps an issue from RESOLVED the same way; no screen can set Deferred yet.)

Review the validation dashboardupdated 2026-10-14

The dashboard shows issue descriptions, affected record counts and overdue dates in a compact list. Try the filters, open an issue, and export the filtered list as CSV (.csv) from the three-dot menu at the end of the filters. Check that the list, issue details and downloads contain only the schools and records you are allowed to see. In the full-screen app, one sidebar parent and the page title follow successful navigation, including issue detail, direct links and browser history; mobile navigation closes the menu and moves focus to the page title. Full screen and inside Aeries show the same single header: Data Validations above the page title.

Open the starting page →

Walkthrough unavailable for this build

Jira

SIS-95 Review the validation dashboard

Test as

Hosted admin (district-wide)
Hosted admin (district-wide)

Build timeline

Build notes are not collected yet for this build.

QA walkthrough

Open Data Validation (beta) > Dashboard.Expect: Data Validations sits in small capitals above the Dashboard title, which shares its row with Open full screen and What’s new. Three balanced summary cards show only the nearest certification date, countdown, status and must-fix count.
Inspect the Dashboard title and the issue rows.Expect: The title uses the shared 24px page heading and is the only heading of its level. Rows have no per-row wand; the chevron at the end of each row is large and vertically centered.
In lab fixtures, preview then acknowledge a batch of open records. Also resolve a record and assign an issue. Return to Dashboard.Expect: Preview changes nothing. After successful apply, fresh API requests update records and issue rollups without a browser reload. Dashboard list and summary counts match the server; partial assignment rollups can show Multiple assignees.
Inspect the filters, then search for AERIES006. Open the three-dot menu at the end of the filters (it reads “More options for issues” to a screen reader) and choose Export to CSV (.csv).Expect: The count sits immediately after the filters. A vertical three-dot button, matching the one on Issue Detail, sits at the right of the same wrapping toolbar. Its menu has one option, Export to CSV (.csv); there is no Excel choice. A .csv file downloads containing only AERIES006, and a line under the filters names the file and says it holds 1 issue (Dismiss clears it). While the file is prepared, the three-dot button shows it is busy, the menu item is disabled and a line with a small spinner reads “Preparing your export, this may take a while”; there is no row limit, so a large export may take minutes, and it must not be started twice.
Clear the search, set a severity or status filter, and choose Export to CSV (.csv) again. Open the file in a spreadsheet and compare it with the dashboard.Expect: The CSV has one header row and one row for every issue matching the filters, including issues beyond those loaded on screen, in the dashboard’s order. Columns cover the rule, description, severity and level, status, record counts by status, assignee, due date, first flagged date, age, rule type, CALPADS code, blocking rule and disabled state, and end with the rule’s guidance: Why this rule exists, How to fix it, Guidance source and Guidance review state (Available, Draft - review required, or Missing - guidance required). A rule with no guidance has those two text cells empty. Dates read yyyy-mm-dd. Only schools and groups you may see are included. A rule name beginning with = + - or @ shows a leading apostrophe instead of running as a formula.
Choose a filter combination with no matches and export in each format. Then, at a narrow (390px) window, open the menu with the keyboard (Tab to the button, Enter, Enter) and press Escape on a second try.Expect: An empty result downloads a file with column headings only, and the line under the filters says no issues match the current filters and search. At 390px the button, its menu and any message stay inside the screen with no sideways scrolling. Escape closes the menu and returns focus to the button. If an export fails or is refused (signed out, no access, busy server, timeout or dropped connection), a red message appears under the filters and nothing is downloaded; the message has one Try again button, which repeats the same export, and Dismiss clears it. A server timeout is reported as a timeout, a dropped connection or a file cut off before its end as “interrupted before it finished”, and a partly received file is never saved.
Find AERIES006. Click its description, blank row space or the right chevron. Repeat using Tab and Enter on the title link.Expect: The description appears beside the code with affected record count and first-detected age below. The full row opens Issue Detail, where the issue can be fixed or sent to Aeries Assistant.
In /app, click the certification card, or focus it and press Enter/Space.Expect: A modal shows distinct dated items with unverified markers and CALPADS practice run has not run yet (or its real last-run status). Run now is available when idle. Escape or Close dismisses the dialog and returns focus to the card.
As a lab system administrator, choose Run now in the certification dialog.Expect: A queued confirmation or a clear server error appears; while queued/running the action is disabled.
Find an overdue issue (or use the overdue demo fixture).Expect: There is no OVERDUE badge beside the title. On the right, the whole “N days past due” phrase is bold red. The due date still opens Extend Due Date and the avatar still opens Reassign. Rows with days left or no due date (—) keep their normal, non-red text.
Find a resolved issue (or use the resolved demo fixture) and compare it with the active rows above it.Expect: A muted green RESOLVED badge sits on the left in the slot WARNING or MUST-FIX uses on active rows, the same size and lined up with them. It no longer appears beside the title. Active rows still show their severity on the left, with BLOCKING beneath it where it applies. If the resolved issue is also past due, its bold red “N days past due” stays on the right. At a 390px-wide window RESOLVED still leads the row. An issue is RESOLVED only when no record is Open, Deferred or Disputed; its row reads "0 open records" and its details line ends with its other records by status, for example "0 open records · Custom · Resolved 2 / Acknowledged 1", and the row stays the standard height. An issue whose only remaining record is disputed or deferred keeps its severity badge, and Status Open lists it.
Compare the issue list with the previous build at the same window size, including a row with a long title, an overdue row and a row with no due date.Expect: Rows are shorter (about 64px instead of 84px), so more issues fit on screen. Every row is the same height and nothing is cut off. The issue title is a little larger and sits closer to its details line. A long title still ends in “…” on one line. At a 390px-wide window, long titles still wrap and the row grows to fit them.
Choose Open full screen beside What’s new in the page header.Expect: The full-screen host opens on the current route. The filter bar has no full-screen link. In full screen, the link is hidden and the header is otherwise identical: no second title bar above it.
Open What’s new and view the dashboard slide.Expect: Its refreshed masked screenshot matches the certification card and overdue layout.
Pick a severity in the severity filter.Expect: Only issues of that severity remain. Needs two or more severities in use; run the DV6 demo seed if the lab has fewer.
Change the status filter, then the sort.Expect: The list refreshes from the server, and the choice survives a page reload.
Change each of the severity, status, assignee and deadline filters and the sort, watching the list as you do. Then change two filters quickly, one after the other.Expect: The previous issues and the count disappear at once and Loading issues… shows in their place; then only the issues for the new choice appear. After quick changes the list always matches the last choice. Typing in the search box still narrows the list instantly, with no loading message.
Type part of a rule name in the issue search.Expect: Only the matching issues are listed.
In another tab, sign out. Back on the dashboard, refresh the list.Expect: You are sent to sign in. After signing in again, the dashboard loads.
Using synthetic records, compare an earlier unassigned Open due date with assigned Open and Deferred dates. Also inspect an issue with only Deferred work and apply deadline filters.Expect: Issue dueDate uses the earliest assigned, nondeleted Open or Deferred date. Earlier unassigned, resolved and deleted dates are excluded. Assignee remains Open-only (Deferred-only shows Unassigned). Deferred-only work is overdue when past due, otherwise mustfix/warning with at-risk inside the reminder window; it is never labeled resolved. Deadline filters use this same dueDate.
After Round 1 is deployed as a batch, use a synthetic issue with more than 50 affected records. Export it, then export the dashboard unfiltered and with search/status/severity filters. Repeat with a school user lacking another group’s read access and with STU read withheld.Expect: The issue file contains the complete authorized list, including records not loaded on screen. The dashboard CSV excludes unauthorized schools/groups; the issue CSV holds only records you may see. Student names are blank without STU read. Exports do not change record states; there is no 10,000-row limit: a large export shows “Preparing your export, this may take a while” until the file arrives, and a failed export saves no partial file. No deployment is needed for the local synthetic tests.
On an isolated SIS-180 test build, sign in as a synthetic district user at school 0, then repeat as a school user. Compare dashboard rows with the CSV download and download a visible issue with more than one page of affected records.Expect: School 0 includes only authorized school memberships; a school user sees only that school. Downloaded rule rows match the filtered dashboard. The affected-record workbook contains all authorized records, with student names only where STU Read is allowed.
Request detail, affected records and export for a denied issue and a nonexistent issue.Expect: Both return HTTP 404 with an empty body. SIS-180 remains parked at PR for review; this walkthrough does not authorize deployment.
With an isolated test build, invoke the four assistant issue reads as the synthetic district user and a single-school user, and repeat after revoking DVR or DVR Read.Expect: Bearer reads use the acting user’s live school memberships and permissions. Counts match equivalent district/school sessions. Denied issues and unmapped identities return empty 404s. MCP read claims remain enabled.
At 1440px, inspect each filter dropdown, then change Severity using the keyboard.Expect: Each shared caret is 8 by 5px, gray, centered vertically and inset 6px from the right. Selecting a filter still narrows the list.
Open the dashboard at /app; refresh and use Back after visiting an issue.Expect: The hash route remains correct in the chromeless DV6 shell; existing filters, permissions and record actions are unchanged.
Open /app on Dashboard, open an issue, and use browser Back and Forward.Expect: Dashboard remains the only selected parent. The page shows Data Validations above the Dashboard title; Issue Detail shows the rule name as its one heading. No separate title bar appears above either, and the selected link has aria-current=page.
Open Rule Browser, expand a rule, and open CALPADS Rules and Create Custom Rule. Enter Field Mapping, administrator Custom Fields and Certification by direct hash link.Expect: One matching parent is selected and the page title under Data Validations names the current screen (Rule Browser, Starter Library, Create Custom Rule, Field Mapping, Custom Fields, Certification), exactly once. Custom Fields keeps its administrator gate; Certification remains coming soon.
At mobile width, navigate from Menu, dismiss with Escape, and use browser history with the menu open.Expect: Successful navigation closes the menu and focuses the page title without scrolling. Escape returns focus to Menu. The Menu button sits in its own bar above the header. Current header typography, drawer spacing and Feedback rounds remain.
With the browser’s network throttled to Slow 4G, open Dashboard, then an issue, Rule Browser, Create Custom Rule, Field Mapping and (as an administrator) Custom Fields.Expect: Each screen’s title, breadcrumbs, What’s new, filters and Add button appear at once. Only the area waiting for data shows three small pulsing dots, centred in that area. There is no “Loading…” text and no blank or blocked page.
Still throttled, open an issue from the dashboard.Expect: The breadcrumbs, Issue #number and What’s new are there immediately. The rule name, badges and records then arrive together. The dots are about half the size of the earlier ones.
Still throttled, change the dashboard Status filter. Then turn on the operating system’s Reduce motion setting and reload.Expect: The filters and summary cards stay usable while the dots show in the list area; an error or “no results” message replaces the dots, never sits beside them. With Reduce motion the dots hold still. A screen reader announces “Loading issues…”.

Ask the assistantupdated 2026-10-13

Ask the assistant about an issue or affected record, then try reopening an earlier conversation from History. Review any proposed fix before confirming; if the assistant is not configured, the drawer explains that.

Open the starting page →

Walkthrough unavailable for this build

Jira

SIS-102 Ask the assistant

Test as

Hosted admin (district-wide)

Build timeline

Build notes are not collected yet for this build.

QA walkthrough

Sign in as admin and open /app#/dashboard (no query string), then open any issue.Expect: The floating assistant button (a small round Aeries Assistant emblem, white on navy, close to the bottom-right corner) shows on every DV6 page. The issue's sidebar section is headed "Choose a Next Action" (no "Escalation") and has an Ask Aeries Assistant button with the blue Assistant emblem, below Acknowledge and Resolve. The button appears only where the Assistant is enabled for the preview by the server.
Click Ask Aeries Assistant.Expect: The drawer opens with "Help me fix <rule>: what's wrong with these records and what should I change?" already sent, and the answer streams in as formatted text (bold, lists, headings; no ** or # markers). Text after each lookup starts a new paragraph. If the drawer says "The assistant isn't set up in this environment yet.", this preview has no Anthropic key or MCP server (or the flag is off), so report it rather than testing further. A failed request never leaves an empty reply bubble or shows a status code.
Close the drawer with ×, then use only the keyboard: Tab to the round Assistant button and press Enter. Type a question without clicking, press Enter, and keep typing while the answer streams. Open History and New conversation, then close the drawer with ×.Expect: Opening puts the cursor in the “Ask me anything...” box once, from the button or from Ask Aeries Assistant. Nothing moves the cursor while the answer streams, a lookup finishes, History opens or a conversation switches; the box stays focused (read-only until the answer finishes). Closing returns focus to whatever opened the drawer: Ask Aeries Assistant or the record wand, or the round Assistant button.
Look at the panel header, suggestions and composer, then click the expand icon in the header. Click it again (or press Escape, or click the dimmed page).Expect: The header is one row: the Assistant icon and the context chip (for example Issue Detail · Issue #4821) on the left, with History, New conversation, expand and close on the right, all centred; there is no “Aeries Assistant” title text. Suggestions are chips inside the panel padding, Send lines up with the text box and the box says “Ask me anything...”. Expand opens the same conversation in a centred dialog; the return arrow, Escape or the dimmed page bring it back to the side panel. Nothing is clipped at 1280, 1440 or 1920 px.
Ask a question that makes the assistant look up records (for example "Which records need a new Next School?"). Watch the drawer until the answer finishes.Expect: Animated dots show right after you send and again after each lookup step, until words arrive. The drawer stays scrolled to the bottom the whole time, including after the lookups. The answer leads with the answer, is short (a few sentences or a small table), and doesn't restate the question.
Ask a how-to question about Aeries itself, without any student details (for example "Who sees Data Validation results, and how does someone become a responsible user?").Expect: A “Read Aeries help” step appears with a Sources link to the official support.aeries.com article (for example Data Validation), opening in a new tab. The answer is based on that article and cites it as a link. It proposes no write and runs nothing. If the help site can't be reached, the step says “Aeries help unavailable” and the answer says so instead of presenting an undocumented answer.
While an answer is still being written, scroll up to an earlier message. Then send another question.Expect: The drawer stays where you scrolled while the answer finishes. Sending the next question jumps back to the latest message and follows it again.
On an issue with more than 200 records (AERIES043 has about 260 on the lab), ask "How many records are there, and how do they break down by school and grade?"Expect: The answer gives the full total and counts by school and grade (it uses the record summary, not just the first page), and never claims to have seen only 50.
Close the drawer, reload the page, then click Ask Aeries Assistant again. Then open a different issue and come back.Expect: The same conversation reopens each time, without sending the starter again. The other issue has its own conversation (empty until you ask).
In Affected Records, click the magic wand at the end of a record row (tooltip "Ask Aeries Assistant about this record").Expect: The row does not expand. The drawer asks "Help me fix record #<id> (student <id>): why is it flagged, and what exactly should I change?" in this issue's conversation, and the answer is about that record. Clicking elsewhere on the row still expands it.
Click New conversation in the drawer header, ask something, then click History.Expect: New conversation clears the drawer and shows the suggested prompts; the earlier conversation is not deleted. History lists both conversations on this issue, newest first, titled by their first question, with the open one marked. Choosing the earlier one reopens it with its full history, and a follow-up there is saved to it.
Open full screen and click the round Assistant button at the bottom right.Expect: The same drawer opens over the current page, with the conversation so far. The page itself doesn't change.
Ask a follow-up in the drawer, then reload the page.Expect: The follow-up uses the earlier exchange, and the conversation is still there after the reload.
Ask it to resolve a record, then click Cancel on the proposed action.Expect: Nothing is written and the cancellation is audited.
Ask again and confirm.Expect: The record is resolved, as if you had done it from the record row.
On a grade-level issue, accept the proposed '1 → Kindergarten' fix.Expect: Students are stored at 0. A typed 'K' is refused, with the valid values listed.
On an AERIES043 issue (Next Grade does not exist in Current School), ask the assistant to fix a record.Expect: It proposes a change to Next School (NS) or Next Grade (NG), the fields that rule checks, with a before/after preview you must confirm. An invalid school or grade is refused with the valid values. It never offers to change key, identity or status fields (ID, SC, BD, TG and so on).
Demo round trip: on AERIES043, tell the assistant which school a matriculating student moves to and ask it to set Next School for that one record. Open View all changes, then Apply fix.Expect: The card shows exactly STU.NS old → new for that record. After Apply the message ends "Verified: 1 of 1 saved exactly as previewed." and the record auto-resolves. Spec 78 restores the student afterwards; if you run it by hand, set NS back the same way.
Ask the assistant to list the affected records as a table (for example "Show the records that need a new Next School as a table").Expect: The answer shows a real table with a header row and columns, not lines of "|" characters. Chat text is 14px, and the drawer opens 480px wide (narrower on a small screen) and can still be dragged wider or narrower.
Close the drawer with ×.Expect: The issue page stays usable. Restore any student you changed (see the data-fix restore journal spec).
In a reset-enabled lab preview, sign in as admin and use AERIES043 at school 990. Ask the assistant to set Next School to 994 only for students 99000016, 99000019 and 99000036; review those exact students and values before applying. Then click Reset demo data in the Lab QA sidebar.Expect: The three demo results reopen with Next School 0 and Next Grade 7. The requesting admin starts a fresh conversation; other students, issues and users' conversations are unchanged, and audit history remains. A second reset has no additional effect. The reset button is unavailable in normal/production builds, outside a valid lab preview, or for non-admin users. Repeated scan duplicates are retired within this demo scope; only the newest result per demo student stays active and opens again.

Edit Student Demographicsupdated 2026-10-13

Try the new student demographics page, save a permitted personal-information edit and check it after reopening. From an issue, use View Data to find and focus the field that failed; known fields are marked and focused, while unknown fields have no guessed marker or fallback message. Address editing is not available in this preview. Oct 10: the header photo is larger and the summary row lines up with the name; Edit only makes inputs of fields the server will save, and every other field stays plain text with no per-field Edit in classic link or (read only) note (use Back to classic at the top of the page to change those); one Save commits student fields and custom fields together or not at all. Editing remains Partial: the backend scalar allowlist is Personal-only; Address, Contact, Background and Language are read-only. New: an administrator can add custom fields to this page on the Custom Fields screen (/app#/custom-fields); they appear in a Custom fields section at the bottom and save with the page. The twelve Personal fields now save the way classic does (name cleanup, classic change log and detail rows). The server can save student fields and custom fields in one all-or-nothing request; this page still sends them separately until its own update lands, so a partial save is still possible from the page. New: the Siblings page is rebuilt in the same style (/app#/students/{studentId}/siblings). It lists the students who share the family key and, in the approved isolated preview, lets permitted staff match the student to an existing family, create a new family key or remove the student from the family. Only that student's family key changes. Oct 11: a sibling's name is a plain link on mouse, keyboard and touch, with no preview card, and opens that sibling's Demographics page at the sibling's own school; the pencil that edits the family key now sits inside the Family key chip (still named Edit family key); only Inactive and Pre-enrolled students show a status badge, an active student shows none, and a status the server did not return reads Status unavailable; Address & contact no longer shows a Validated/Not validated badge or a Verified date. SIS-246: this page now takes its layout styles and its student reads from a shared record-page base that later rebuilt pages will reuse; nothing on the page should look or behave differently. Oct 11: read-only values on the Demographics and Siblings pages copy when clicked (or focused and activated with Enter or Space), with a brief Copied! confirmation; links, inputs, placeholders and the verification pass code are not copy targets. Contacts: open the read-only Contacts page by URL and compare its list and order with classic Contacts. SIS-321: Go to field now leads to a fix. A field a data validation fails on that this page cannot edit says why next to its value (not editable on this page yet, with a link to classic Demographics); Birth city and Reporting lang. can be edited right there, and after Save changes the page rechecks the validation and names the ones that cleared. SIS-353: student photos on Demographics and Siblings load together instead of one after another, and opening a page again reuses the photos the browser already has once the server confirms you may still see them. SIS-355: Edit follows the district's Required Fields setup for the thirteen editable fields, as classic Save does: a required field shows * and cannot be saved blank, and Birth state is required only when Birth country is US, CA or MX. Classic's advisory warnings appear as notes that do not block Save: Birth state does not match Birth country, and a birthdate over 75 years ago. A current code that is no longer in the code list is shown instead of a blank choice. SIS-354: only staff with Data Validations access to a rule's group and school see the validation panel and its count; each row has a Re-check validation icon that shows Re-scanning, then still failing or could not re-check, or removes a cleared record from the list with a green notice. SIS-352: the photo now runs the full height of the name, school and facts block; the per-field blue Edit links are gone (double-click a field, or use Edit at the top right, which now reads Edit); View Data opens the page and goes to the failing field once it knows which fields you can edit; Reporting and correspondence language read code first (01 - Spanish) in the view and the picker, and other coded fields show their descriptions the way classic does, even when you cannot edit them; Unpin brings you back to the field with a brief blue outline; Clear in Pinned fields removes all your pins after a confirmation.

Open the starting page →

Walkthrough unavailable for this build

Jira

SIS-103 Edit Student Demographics

Test as

Hosted admin (district-wide)
Staff user
Hosted admin (district-wide)

Build timeline

Build notes are not collected yet for this build.

QA walkthrough

In the named DV6 isolated preview, select a student that exists in that preview’s clone (the former fixture 99000884 at school 884 is not in generated clones; never 88400138). Note the current values first and restore them after. Open classic Demographics.Expect: The selected student is synthetic. Try the new version is visible for staff when DV6 is enabled.
Select a synthetic demo-seed student at school 992 or 994. Open classic Demographics.Expect: With DV6 enabled, Try the new version sits immediately to the right of Demographics on its title line, before flag, favorite and print. At 1024, 1280 and 1440 pixels, the row height and next content Y match feature off; neither the action nor icons wrap. Capture a screenshot of each state.
Using only the isolated synthetic preview, compare the same classic Demographics page with DV6 off and on. Open Contacts, which supplies no new-version URL.Expect: Feature off emits no action or spacer. The content below and icons have the same positions in both states. Contacts has no stray new-version spacer.
Tab to Try the new version and press Enter. Revisit classic, then use Back to classic and reload.Expect: The link preserves student 99200712, school 992 and year. Keyboard activation saves the database/user-scoped modern preference; revisiting classic redirects. Back to classic saves classic preference and stays classic after reload.
Click Try the new version.Expect: The same student, school and school year open at /app#/students/{studentId}/demographics in the chromeless DV6 shell. The redesigned header and eleven sections remain; Back to classic is available and the full-screen launch icon is absent.
Compare the header, summary strip and section cards with the Student Profile Redesign.Expect: The redesigned header and cards remain intact. Edit is enabled only for authorized staff and students at any school in the approved named lab preview. Previous/Next remain unavailable. Readable update-denied fields stay read-only. Address & contact shows no Validated or Not validated badge and no Verified date under Residence street.
Click to copy: on the new Demographics page for a synthetic student, click the Student ID in the header. Then press Tab until Gender in the summary row is focused and press Enter. Paste each into a scratch text field.Expect: Each pasted value is exactly what the page shows. A small Copied! appears beside the value with a gap, fades and disappears within about two seconds; with reduced motion turned on it appears and disappears without fading. Nothing navigates, no edit starts on a single click and nothing is saved. The email and phone links still open mail and phone, a dash placeholder cannot be copied, and after Edit the inputs are ordinary inputs.
On a synthetic student with Next school missing, find the Next year section.Expect: Next school remains highlighted; Go to Next year scrolls there. Use the section Edit or Edit to set a permitted next school.
For a demo student with an open AERIES010 issue, click Go to Next year.Expect: The real issue banner targets the Next year section and adds a shareable section query parameter.
Click Show for the masked verification pass code using a user without explicit field read permission.Expect: The code stays masked and a permission message appears.
In /app, check Back to classic; then open a former .aspx student deep link with the same school and year.Expect: The former entry redirects to /app and retains the student hash route, school and year. The full-screen icon is absent in this canonical shell. Back to classic returns to classic Demographics for the same student.
Click Back to classic, then reopen Demographics.Expect: The same student and school are retained. The classic preference is remembered for this user.
Using synthetic staff with a denied Student field, open the modern page and request that field explicitly through v6.Expect: Permitted fields and sections render. The denied field is omitted from both default and explicit responses with no placeholder or permission metadata. VPC stays masked without its grant.
Click Edit, change a permitted field on synthetic student 99000712, then Save changes and reload.Expect: The sticky footer counts changed fields. Save sends only changed allowlisted fields and expected values. A green message above the footer names the saved fields, read back from the server. The saved value persists after reload; a LOG audit commits with the change.
Personal save, classic readback: on synthetic student 99000712 at school 992, click Edit, set First name to " Ana " (with spaces) and Birth city to "Demo City", Save changes, then reload. Click Back to classic and open Demographics for the same student.Expect: The new page and classic both show First name Ana (spaces removed) and Birth city Demo City. In the database change log (LOG table, or the classic Change Log report for this student) there is one "Aeries Web Student Data - Submission (v6; ...)" entry for this save under your user name, listing FN and BCY with old and new values, and one "Aeries Web Student ID Numbers - Submission" entry for FN. On a record classic has not saved recently the first entry may also list SX, VPC (value not shown), INE or CHT: classic sets these on any save.
Personal save, each field: repeat for Last name, Middle name, Suffix, Gender, Birthdate, Birth state, Birth country and the three alias names, one at a time, reloading after each.Expect: Each value persists after reload and matches classic Demographics. Any field you cannot update has no editor.
Personal save, refused: change First name, and before saving have a second signed-in session save a different First name for the same student. Then click Save changes in the first session.Expect: Nothing is saved by the first session and no change-history entry exists for it. The page re-reads the record: First name is marked with a message that it changed and shows the value it now holds, and the first session's edit is kept. Saving again replaces the value on purpose.
Edit Personal, clear First name, and click Save. Then Cancel.Expect: An inline required-field error appears; no request is sent. Cancel restores the original values.
Try a readable but update-denied field, including a direct scoped request.Expect: No editor is exposed for the field; it keeps its value as plain text, with no link or note beside its label. A denied request returns 403 for the whole save; no changed value or audit is committed. The page re-reads the record and names the field that can no longer be edited, without showing any value the user may not read. Other edits and their count are kept.
Save a permitted edit and inspect the summary, then submit a field with a server-side validation error.Expect: Student ID, State ID, Stu#, grade and, for an Inactive or Pre-enrolled student, the status badge survive the save refresh. A 400 response with fieldErrors appears beside its matching editor; the draft and unsaved count remain.
Review a permitted name or birthdate save and a refused pre-enrollment-locked save against synthetic SQL records.Expect: The accepted write updates STU, IDN, DTS and before/after LOG atomically. A locked-field 403 changes none of them; WebForms session student selection does not control the route student.
Open Edit and inspect Address and Next year; submit a forged address or EOY/SWR/HSG/DG/ENS/SLD/SNS update.Expect: No editors for those fields. Address payloads are refused with metadata-free 403; removed fields with 400. No STU/IDN/LOG/LGD change.
Save an authorized synthetic name with configured SyncFlds and a dynamic FN group; inspect SQL rows and linked audit/hook data.Expect: Only authorized configured school copies change. Every changed STU has LOG/LGD, DTS and its hook; the classic selector adds/removes relevant memberships. Any audit/hook/group/copy failure rolls the entire transaction back.
In an environment missing the named host, matching named deploy marker or approved lab write setting, call demographics-edit and demographics-update directly.Expect: Both refuse with 403 lab_editing_unavailable, without field metadata or student/audit writes.
On this preview, use a synthetic student with a confirmed builder rule checking Next school equals zero. Open the issue, expand the record row, and activate View Data with Enter.Expect: The same student, school and resolved year open. Next school is visibly marked with text, scrolled into view and focused; a screen reader can read the validation indication.
Use a two-operand supported builder rule, then repeat with an omitted field, a denied record, stale mapping or unsupported rule/page.Expect: All available operands are marked and the first receives focus. Denied data is never shown. Unknown mappings show no guessed field or fallback message; the student validation banner remains visible.
While signed in, open a synthetic student with validations and expand the collapsed validation summary. Use Go to field for a verified field returned on the page, then use Rule details for an unmapped rule.Expect: Go to field focuses and outlines the verified field. Rule details opens the unmapped rule’s issue; no field is guessed.
Open a readable synthetic student while demographics-edit is delayed, then returns 403 lab_editing_unavailable. Repeat with 200 capabilities and HTTP callbacks outside Angular’s zone.Expect: The student name, readable fields and validation banner settle without clicking or waiting for editing. A 403 keeps edit actions disabled and sends no mutation. A 200 enables only the returned readable fields.
Expand and collapse the data validations panel using Enter.Expect: The disclosure caret is half its former size and gray (#888), and the validation rows still show and hide.
Reviewer: read back s04.png, s05.png, s06.png and desktop walkthrough View, Edit and Saved before reviewing SIS-103.Expect: Confirm popup overlap, redundant Read only rows, and the red Next School state in the references.
Double-click a permitted field value in view mode. Repeat with its Edit button using Enter, Space and a touch tap.Expect: Editing opens and focuses that field without scrolling to Edit. Read-only fields have no field Edit button and ignore double-click.
Open Edit at 1440px and scroll through Personal, Address, Background and Next year.Expect: Each field the page cannot save keeps its value as plain text in the same place, with no extra row, no moved field and nothing beside its label. Missing Next School remains red. The sticky save bar sits 8px above viewport bottom. There is no My notifications box on this or any other DV6 page. Tab moves from editor to editor and skips the plain-text fields; no Edit in classic or (read only) text appears anywhere on the page.
Repeat with denied capabilities and partial field update rights; save a draft with a validation error or permission denial.Expect: Only returned write capabilities expose editors. Read permission grants none. Save errors retain drafts. Address is disabled server-side; Contact/Background/Language are outside the current write allowlist.
On embedded and full-screen Student Demographics, open Edit and scroll to Next year. Then navigate to Dashboard.Expect: Nothing overlaps the assistant button or the sticky save bar, and no My notifications box appears on either page. Read-only fields are plain text and are not tab stops. Broader section editing remains Partial.
Oct 10 header: Open a synthetic student in the new Demographics page at 1440px, then at 390px.Expect: The round initials photo is 84px across (1.5 times the earlier 56px). At 1440px the Age, Gender, Language fluency and Primary teacher row starts at the same left edge as the student's name. At 390px the name sits under the photo and the row still starts at the name's left edge; nothing runs off the page.
Oct 10 edit: Click Edit and look through every section. Tab through the Address & contact section.Expect: Only the twelve Personal fields (last, first and middle name, suffix, gender, birthdate, birth city, state and country, and the three alias names) and editable custom fields are inputs. No input is disabled or dead. Every other field, in every section and in Custom fields, keeps its value as plain text: no Edit in classic link, no (read only) note and no hover explanation. Tab does not stop on them. Back to classic at the top of the page opens classic Demographics for the same student and school, and All contacts in the family card opens classic Contacts. Verification pass code keeps its Show button, which only reveals the value.
Oct 10 edit: With unsaved edits, click Back to classic at the top of the page and choose Cancel in the prompt.Expect: The page asks before discarding. Cancel keeps the edits and stays on the page.
Oct 10 edit: Click Edit and change nothing. Then change a field and change it back.Expect: The footer says No unsaved changes and Save changes is disabled both times. No request is sent.
Oct 10 edit: Start a save, then cut the network before the response arrives (browser offline, or stop the request in DevTools).Expect: The message says the save could not be confirmed and the edits are kept. Save changes is disabled and Check record is offered. With the network back, Check record re-reads the record and says which edits are already saved; nothing typed is lost.
Oct 10 edit, one Save for both: on synthetic student 99000884 with an editable custom field, click Edit, change First name and the custom field, and Save changes once. Reload, then check First name in classic Demographics.Expect: The browser sends one request (POST demographics-update with customFields). The green message names both fields. After reload the page shows both new values and classic shows the new First name.
Oct 10 edit, one Save refused: change First name and type abc in a whole-number custom field, then Save changes. Reload without fixing it.Expect: Nothing is saved: the message beside the custom field names the rule, First name still has your edit in its box, and after the reload both fields show their old values. No change-history entry exists for First name.
Custom fields: Sign in as admin and open /app#/custom-fields (Custom Fields in the left sidebar).Expect: The Custom Fields screen opens in the same shell as Data Validations. It lists the fields that exist, or says there are none yet, and has an Add Custom Field button.
Custom fields: Click Add Custom Field and look at the new-field row before typing.Expect: Title, Type and Page are the same height and sit on one line, with their headings level above them. Typed text and the dropdown values start the same distance in from the left border.
Custom fields: Enter the title Intervention tier, choose Whole number, leave the page as Student > Demographics, and click Create field.Expect: The field appears in the list with its type, its page, a generated identifier (you never type a code), and who created it and when. If Intervention tier already exists from an earlier run, use another title.
Custom fields: Click Add Custom Field again and enter the same title for the same page.Expect: The save is rejected. The message names the title and the page, and what you typed stays in the form.
Custom fields: Open a student that exists in the clone in the new Demographics page (/app#/students/<studentId>/demographics?schoolId=<schoolId>&schoolYear=2026) and scroll to the bottom.Expect: A Custom fields section is the last card on the page. It shows Intervention tier with a dash, because this student has no value yet.
Custom fields: Click Edit at the top of the page.Expect: Intervention tier becomes a text box in the same place and at the same size as its value. The section has no Edit, Save or Cancel of its own.
Custom fields: Type abc in Intervention tier and click Save changes.Expect: Nothing is saved. abc is still in the box, and the message beside it says Intervention tier must be a whole number.
Custom fields: Replace abc with 2 and click Save changes. Then reload the page.Expect: The page leaves edit mode and Intervention tier shows 2. After the reload it still shows 2.
Custom fields: Click Edit, change the value, then click Cancel.Expect: The custom field goes back to its saved value along with the rest of the record.
Custom fields: Sign in as test (a staff user who is not an administrator) and open /app#/custom-fields.Expect: There is no Custom Fields link in the sidebar and no Add Custom Field button on the screen; it says custom fields are managed by administrators.
Custom fields: Open classic Demographics for any synthetic student and look at the User Fields and their captions.Expect: They are unchanged: this feature adds its own storage and does not touch User Fields or captions.
Pinned fields: with nothing pinned, open a synthetic student in the new Demographics page and look between the student summary and the Personal section. Then move the mouse over a few fields without clicking.Expect: There is no Pinned fields card: Personal follows the summary directly. No pin icons show at rest; a field's pin appears at its top right only while the mouse is over that field.
Pinned fields: hover First name and select its pin, then do the same for Birth city, Student email and a custom field. Then pin a field in another section.Expect: The first pin brings in the Pinned fields card, whose header says Saved for you in this browser only: pins are kept in this browser for the signed-in user, do not follow you to another browser or device, and nothing about them is sent to the server. Each field appears in Pinned fields in the order you pinned it and stays in its own section, where its pin is now filled in. The verification pass code, the header facts and fields that show a dash because this preview has no data for them have no pin.
Pinned fields, finding the new pin: scroll down to a later section and pin a field there, first with the mouse and then with Tab and Enter. Repeat with the operating system set to reduce motion.Expect: The page moves to Pinned fields and the new copy has a blue outline that pulses twice and fades after about ten seconds, like the red outline on a field checked by a validation. With reduced motion the outline does not pulse or fade; it stays blue until it is removed. Keyboard focus is on that copy’s Unpin, and pressing Enter there removes the pin and returns to the field you pinned.
Pinned fields: reload the page, then open a different synthetic student.Expect: The same fields are pinned in the same order, showing each student’s own values. Only the field names are remembered, never a student or a value.
Pinned fields, editing: click Edit and type in the pinned First name box. Scroll to Personal. Then type in the Personal box and scroll back up.Expect: Both boxes always hold the same text. The footer counts 1 unsaved change, not 2. A pinned field you cannot edit stays plain text in both places. While editing, the fields in their sections show no pin, so Tab moves from box to box as before; a pinned copy keeps its Unpin.
Pinned fields, saving: on a synthetic student in the approved isolated preview only, click Save changes, then reload.Expect: One save is sent. The green message names the field once, and both the pinned copy and its section show the stored value after the reload.
Pinned fields: clear First name in the pinned box and click Save changes. Then Cancel.Expect: The required-field message appears under both boxes and nothing is sent. Cancel restores the value in both.
Pinned fields, keyboard: without the mouse, Tab to a pin and press Enter or Space. In Pinned fields, Tab to Unpin for that field and press Enter. Repeat until nothing is pinned.Expect: Each pin appears when Tab reaches it, with a visible focus ring and a name such as Pin Birth city to the top of the page. Unpin removes the pinned copy and puts focus on that field’s pin in its section. Unpinning the last field removes the whole Pinned fields card.
Pinned fields, permissions: pin a field as admin, then sign in to the same browser as a user who cannot read that field and open the page. Sign back in as admin.Expect: The other user has their own pins and never sees yours. A pinned field that a record does not return for you is simply not shown in Pinned fields; it comes back when the field is returned again.
Pinned fields at 390px wide: pin five fields and scroll the page.Expect: Pinned fields stack in one column. Nothing is cut off and the page does not scroll sideways.
Pinned fields with browser storage blocked (a private window with site data blocked): pin a field, then reload.Expect: The pin works until you leave the page. The header says pins cannot be saved in this browser, and after the reload nothing is pinned.
Siblings: in the isolated preview, select a synthetic student who shares a family key with another synthetic student (never a real student). Open classic Siblings and click Try the new version.Expect: The same student, school and year open at /app#/students/{studentId}/siblings. The header matches the new Demographics page. The card shows Family key N in a gray chip with a pencil inside it and one row per other student with that key. On a desktop-width window the rows form a compact table under the headings Student, Grade, Birthdate, Gender, Parent/guardian, Phone and Address. The Student cell has three lines: the name (with a status badge only if the student is Inactive or Pre-enrolled; an active student shows none), the school, then Student ID with the whole number, visible without pointing at it and never shortened. Grade, birthdate and age, gender, parent/guardian, phone and address follow in their columns; a long value wraps instead of being cut off, and a field you may not read shows a dash. Back to classic returns to classic Siblings, which still has Sibling Lookup.
Siblings click to copy: on a synthetic student with siblings, click the Family key number, a sibling’s Student ID and a sibling’s Phone. Paste each into a scratch text field.Expect: Each pasted value is exactly what the row shows, with the same brief Copied! confirmation. The sibling’s name is still a link to that sibling, the family key is unchanged and no save is sent.
SIS-350 copy hover: on Demographics and Siblings, point at a value that copies (the Student ID in the header, a sibling’s Phone).Expect: The pointer is the ordinary pointing hand, with no green plus. The value gets a light blue background that reaches a little (3 pixels) past the text on the left and right; there is no added border line. Clicking still copies and shows Copied!.
SIS-350 inputs: choose Edit on Demographics and type a long value into a text field such as Birth city; on Siblings click Edit family key and look at the Find by dropdown and the Student ID box beside it. Repeat inside the classic SIS page, in full screen and at 390 pixels wide.Expect: Typed text runs to within a few pixels (4) of each box’s right border and still starts the usual distance in from the left. Find by’s text starts the same distance in from the left as the Student ID box beside it, and its arrow is a small grey (#888888) triangle, centred top to bottom, 8 pixels from the right edge, never overlapping the text. Dropdown arrows elsewhere keep their space. Classic pages outside the new screens look as before.
Siblings: compare the rows with classic Siblings for the same student, then open a sibling from its name (include a sibling at a different school than the current student).Expect: The same students are listed in both, apart from students you cannot open, which the new page counts in one line without any detail. A sibling's name opens that sibling's Demographics page at the sibling's own school; from there use the page's own navigation to reach its Siblings page, which lists the first student back.
Photos, Oct 11: open the new Demographics page for a synthetic student whose photo shows in the classic student header, then open Siblings for the same student. Compare with the classic student header and classic Siblings.Expect: The initials show first and the round photo replaces them when it loads, in the header of both pages. Each listed sibling that shows a photo on classic Siblings shows the same photo beside the name here, including a sibling whose photo is an older picture file rather than an uploaded one, and the row for the same student at another school. Photos appear as you scroll to a row, not all at once. The sibling preview card and the Match to an existing family preview still show no photo.
Photos, Oct 11: open a synthetic student with no photo on file, and a family where one sibling has no photo.Expect: The header and that sibling's row keep the initials, with no broken-image icon, no empty circle and no message. A student whose only photo is an older picture file shows initials in the header, as the classic header does, and the photo in a sibling row. The name, links and everything else on the page work as before.
Photos, Oct 11: sign in with a lab/demo account whose own permissions or group set Read on the student Photo field (STU.BM) to Deny, open a synthetic student who has a photo, then open Siblings. Repeat with a lab/demo account that cannot open one sibling's school.Expect: The header keeps the initials on both pages, exactly as when there is no photo: nothing says a photo exists or was withheld. Listed siblings still show their photos, as classic Siblings does (classic does not apply the Photo field restriction to the sibling list). A sibling at a school the account cannot open is only counted and never shown, so no photo is requested for it.
Photo speed (SIS-353): sign in with a lab/demo account, open Siblings for a synthetic student with several siblings who have photos, and watch the photos arrive (browser developer tools, Network tab, filter photo). Then reload the page, open the same student again from another page, and sign out and back in as a different lab/demo account that can open the same family.Expect: On the first open the row photos arrive at about the same time rather than one every half second. On reload or a second visit in the same browser the photos appear at once; Network shows each photo asked for again and answered 304 (no new image bytes) after the server rechecked access. A different account, or a student whose photo was replaced, gets the full photo (200). An account that may no longer see a photo gets initials, never the earlier picture.
Siblings table widths: with a synthetic student who has siblings, make the browser window narrower step by step down to a phone width (or use device mode at 390 wide), then widen it again.Expect: Below about 1100 wide the headings row goes away and each sibling becomes a block with every value labelled (Grade, Birthdate, Gender, Parent/guardian, Phone, Address). At every width the full student ID, school and address stay visible and the page never scrolls sideways.
Siblings names: on a synthetic student with siblings, point at a sibling's name with the mouse, then Tab until the name has focus and press Enter. Go back, and on a phone (or a browser's device mode with touch at 390 wide) tap the name once.Expect: The name is a direct link on mouse, keyboard and touch: no preview card opens on hover, on focus or on a tap, and the first tap follows the link. It opens that sibling's Demographics page (/app#/students/{studentId}/demographics) at the sibling's own school, which can differ from the current student's, in the same school year. A sibling you cannot open is still only counted and has no link.
Siblings: on a synthetic student with no family key, click the pencil in the Family key chip (named Edit family key), keep Match to an existing family, enter a sibling's student ID, click Find family, then Match to family N. Reload, then open classic Siblings for both students.Expect: The preview names the family before anything is saved. After saving, a Saved message shows the key, both students list each other after reload, and classic Siblings shows the same family for both. Only the first student's family key changed; the sibling's record was not edited.
Siblings: on another unmatched synthetic student, choose Create a new family key and save. Then choose Remove from family and save.Expect: The new key is one above the highest family key in the district and is shown after saving. Remove from family sets the key to 0 and shows the No siblings state; the option is unavailable while the student has no key.
Siblings: try to match a student to its own ID, to a student with no family key, and to the family it is already in.Expect: Each explains why there is nothing to match and sends no change.
Siblings: sign in as staff with SIB Read but without SIB Update, then as staff with an explicit Update Deny on STU.FK, and open the page. Repeat with a direct request to the family-key route.Expect: The family is shown and the pencil in the Family key chip (Edit family key) is disabled. A direct request is refused with 403 and nothing is written: the family key, the student's change timestamp and the audit log are unchanged.
Siblings: sign in as staff without SIB Read and open the page; then as staff who cannot open one sibling's school.Expect: Without SIB Read the page says siblings cannot be viewed and shows no family. With one sibling out of reach, that sibling is counted as not shown and none of their details appear.
Siblings: open the editor in two browser tabs for the same synthetic student. Save a change in the first tab, then save a different change in the second.Expect: The second save is refused: nothing is saved, the page says the family key changed, and Reload family shows the stored key.
Siblings: after a permitted save, check the synthetic student's audit history (STU change log) and, where the student has a record at a second school with family key syncing configured, that record.Expect: One STU change entry records the old and new family key with the signed-in user. The second-school record carries the same key only where you could have made the same change there. No audit entry exists for any refused attempt.
SIS-246 (shared record-page base): open the new Demographics page for a synthetic student at 1440 pixels wide. Look at the header, summary row, every section card, Pinned fields with a pin or two, the validations banner and Edit. Then open the page for a student or school you may not view.Expect: Everything looks and works as it did before this change: same layout, colours, spacing and buttons, the same values, and edits save as before. The student you may not view shows only the message that the record is unavailable with your current field or school permissions, with no student data.
Page menu: open the new Siblings page for a synthetic student with siblings at 1440 pixels wide, then open Demographics, the Dashboard, an issue, Rule Browser, Field Mapping and Certification. Look at the top right of each page.Expect: Every page has one Page menu: a three-dot icon with no Page word, always the last control at the far right of the header row (after Open full screen and What’s new, or after Back to classic and Open full screen on the student pages). Nothing in the header moves or changes height while the page finishes loading or after. Selecting it opens a menu whose first item is Quick Print. Repeat inside the classic SIS page, in full screen and at 390 pixels wide.
Page menu, keyboard: Tab to the three-dot Page menu, press Enter, press the Down arrow, then Escape.Expect: The three dots show a focus ring. Enter opens the menu with Quick Print focused, the arrow keys move between items and Escape closes it and returns focus to the three dots. The button is named Page menu for a screen reader.
Quick Print: on the Siblings page open the three-dot Page menu, then choose Quick Print, and look at the browser’s print preview (inside the classic SIS page and in full screen). Cancel the preview.Expect: The preview shows only the student, the Siblings heading with its count and family key, and each member with grade, birthdate, parent/guardian, phone and address, on white, with no Gender column, sidebar, classic header or left navigation, buttons, edit pencil, editor, preview card, assistant button or Page menu. The content runs the full width of the paper with no grey page background and no card border, the Grade and Inactive badges and the family key are plain outlines with black text, and names are black, not blue links. Each round picture keeps its size and place beside the name: a student with a photo prints the photo alone with no initials on or beside it, and a student without one prints a single set of initials in the circle. No member row is split across pages. After you cancel, the page looks exactly as before.
Print Siblings: open the three-dot Page menu, then choose Print Siblings, for a synthetic student whose Aeries selection matches this page. Repeat while the request is slow.Expect: While the report is being prepared the item reads Preparing report… and cannot be chosen twice. Then the page says Print Siblings report requested with an Open report viewer link, and classic’s Report Viewer popup opens when the page is inside the classic SIS page. Print Siblings is not offered while the siblings are loading or if they could not be read.
Print Siblings, refused: try it as staff without permission to print, and for a student or year that is not the one selected in Aeries.Expect: Without permission the page says you do not have permission to print the Siblings report. For another student or year it says Print Siblings prints the student and year selected in Aeries, which is not this page, and offers Open classic Siblings. Nothing is printed in either case.
Contacts (SIS-247, read only): In the isolated synthetic preview only, sign in as a synthetic staff user whose groups have full CON Read at school 992 (allowed role). Choose a synthetic demo-seed student at school 992 with several contacts, including one with a restricted record type, one with a red flag and one with missing values, and note the order and values in classic Contacts.Expect: The student is synthetic. Classic Contacts lists the contacts in its usual order, red-flagged first.
Contacts (SIS-247, read only): Open /app#/students/<student id>/contacts?schoolId=992&schoolYear=<signed-in year> by URL. This card adds no link from classic or from Demographics, so paste the URL.Expect: The Student Contacts page opens with the student's name, school and Student ID. A Contacts card shows a count and one numbered row per contact.
Contacts (SIS-247, read only): As the allowed role, compare the list, its order and each value with classic Contacts for the same student: name, relationship, home, cell and work phone (with extension), email, address, lives with, primary contact, ed rights holder, portal access, record type, notification preference, correspondence language and comment.Expect: The rows are in the same order as classic Contacts and every value matches. Phones read (###) ###-####, an email is a mailto link, a code shows its description. No cell says Withheld.
Contacts (SIS-247, read only): As the allowed role, find the contact with a restricted record type and the red-flagged contact.Expect: Both are listed in the same place as in classic. The restricted contact shows its record type description. The red-flagged contact has a Red flag pill and no other row does.
Contacts (SIS-247, read only): As the allowed role, find a contact with missing values.Expect: Every empty value shows a dash, a contact with no name shows No name entered, and nothing says Withheld.
Contacts (SIS-247, read only): Sign in as a synthetic staff user with an explicit Read deny on one CON field, for example CON.TL (field-denied role), and open the same URL. Compare with classic Contacts for the same student.Expect: The Home phone value of every contact says Withheld, and classic hides the same field. The other values on every row, and the order, are the same as in classic.
Contacts (SIS-247, read only): Sign in as a synthetic staff user with an explicit Read deny on CON.AD and no deny on CON.CY, CON.ST, CON.ZC, CON.ZX, CON.AT or the name fields, and open the same URL for a contact that has a full address, an address type and a mailing name different from the name. Compare with classic Contacts for the same student.Expect: Address says Withheld on every contact. No street, city, state, ZIP, address type or Mailing name line appears anywhere on the row, and classic shows none of them either. Name, phones, email, the other values and the order are the same as in classic.
Contacts (SIS-247, read only): Sign in as a synthetic staff user without CON Read at school 992 (denied role) and open the same URL, then open classic Contacts for the student.Expect: The student's name still shows, and the Contacts card says you do not have permission to see this student's contacts. No contact is listed. Classic hides the list too.
Contacts (SIS-247, read only): Open the page for a synthetic student that has no contacts.Expect: The Contacts card shows a count of 0 and says no contacts are listed for this student.
Contacts (SIS-247, read only): Select Back to classic at the top right, then return and select Open in classic Contacts on the card. Then open the page from a validation issue's rule (add &dv6Rule=<rule id> to the URL) and check the breadcrumbs.Expect: Both links open classic Contacts for the same student and school. With a rule, a Rule details crumb leads back to the rule, a Demographics crumb leads to that student's Demographics page, and Back to classic keeps the way back to the validation.
Contacts (SIS-247, read only): Check the whole page for inputs, selects, text areas and any Save, Edit, Add or Delete button.Expect: There are none. Nothing on the page can be edited.
Contacts (SIS-247, read only): Open #/students/<student id>/contacts?schoolYear=<signed-in year> with no schoolId.Expect: The page asks you to select a student, school and school year in classic Contacts, shows no student data and makes no contacts request.
Go to field fix (SIS-321): Open the new Demographics page for demo student ID 99400798 at school 994 and expand the data validations panel. Note the blank Birth city and the Reporting lang. value before you change anything.Expect: The panel lists six data validations, including AERIES-004, AERIES-007, AERIES-008, AERIES-013 and AERIES-025.
Go to field fix (SIS-321): Select Go to field on Missing Birth City (AERIES-007), press Enter on the outlined Birth city (or double-click it), enter a city and select Save changes.Expect: The page scrolls to and outlines Birth city. After the save the notice says the change was saved and that Missing Birth City (AERIES-007) was cleared, and the panel count drops by one.
Go to field fix (SIS-321): Select Go to field on Invalid Reporting Language (AERIES-025), press Enter on the outlined Reporting lang. (or double-click it), choose English (00) and select Save changes. This student's Language fluency is English Only, so English is the value that satisfies the rule.Expect: The notice says the change was saved and that Invalid Reporting Language (AERIES-025) was cleared, and the panel count drops by one. Language fluency, which the rule also checks, says it is not editable on this page yet.
Go to field fix (SIS-321): Select Go to field on Missing Counselor/Teacher (AERIES-004), then on Missing US School Less than 3 Years (AERIES-013).Expect: The page scrolls to and outlines the field as before. The field says "Not editable on this page yet." with a "Change it in classic Demographics" link that opens classic Demographics for the same student.
Go to field fix (SIS-321): Restore the record. Set Birth city and Reporting lang. back to the values you noted in the first step (blank Birth city) if the record should fail those rules again.Expect: The saved values are put back. The two cleared validations stay cleared until they are checked again; to see them open sooner, use Reopen on the record in the issue's Resolved tab.
Required fields (SIS-355): In classic Demographics and in the new page, open Edit for the same synthetic student with the same account. Note which of the thirteen editable fields show * in the new page.Expect: Last name, First name, Gender and Birthdate always show *. Any other editable field shows * only if it is listed for Students in the district's Required Fields setup (classic shows those in light cyan). With no extra fields listed, Middle name, Suffix, Birth city, Birth country, the aliases and Reporting lang. have no *.
Required fields (SIS-355): Only in an isolated preview where changing Required Fields setup is approved for this check: list Middle name and Birth state as required, note the student's Middle name, Birth state and Birth country, then reopen Edit. Clear Middle name and select Save changes. Undo this setup change at the end.Expect: Middle name shows * and the save is refused with "This field is required." at Middle name; nothing is saved. Classic Save of the same blank Middle name is refused too ("You must put in a valid value in the MN field.").
Required fields (SIS-355): With Birth state still required, set Birth country to FR and clear Birth state, then save. Restore, then set Birth country to US with Birth state blank and save.Expect: With FR the save succeeds: Birth state is not required for a country other than US, CA or MX. With US the save is refused at Birth state ("This field is required.") and nothing is saved, as classic refuses it.
Advisories (SIS-355): Set Birth country to US and Birth state to a Mexican state (for example AG), then set Birthdate to a date about 80 years ago. Read the notes, then select Cancel.Expect: Birth state shows "Birth state does not match birth country." and Birthdate shows the over-75 note. Neither is an error and neither blocks Save; classic shows the same two as alerts. Cancel leaves the record unchanged.
Required fields (SIS-355): Restore every value you noted and remove the Required Fields setup you added.Expect: The student's values and the district's Required Fields list are back to how you found them; classic and the new page again show the same * fields.
Row Re-check (SIS-354): Sign in as admin, open a synthetic student at school 992 that has open data validations, and expand the data validations panel. Note the count, then select the Re-check validation icon on one row (with the keyboard: Tab to it and press Enter). Select it again while it runs.Expect: That row shows Re-scanning and its icon is disabled, so the second select sends nothing. The other rows are untouched.
Row Re-check (SIS-354): Wait for the re-check to finish on a row whose record now passes its rule (for example after saving Birth city for Missing Birth City, AERIES-007, or right after Reopen).Expect: The row leaves the list, the count drops by one and a green notice says Re-checked: the rule (its code) is cleared. The remaining rows stay after the list reloads.
Row Re-check (SIS-354, alternate path): Select Re-check on a row whose record still fails its rule.Expect: The row stays, its count is unchanged and it says Re-checked: still failing; the notice says the rule is still failing and is not green.
Row Re-check (SIS-354, alternate path): If a re-check cannot run (for example the server returns an error), select Re-check on a row.Expect: The row says Could not re-check, and the notice says nothing was changed and to try again. It never says cleared and nothing is removed.
Row Re-check (SIS-354, alternate path): Open the same student as a staff account without Data Validations access to that rule's group or school (use test or sysadmin if they lack the access; if every lab account has it, note that and skip).Expect: The student record shows with no data validations panel, no count and no Data validations are unavailable message.
SIS-352 photo: Open a student with a photo on the new Demographics page, then narrow the window to phone width.Expect: The photo is a portrait frame on the left that runs from the top of the name down to the Age row. On a phone it is smaller and still beside the name and facts.
SIS-352 Edit: Look for blue Edit links beside field labels, then select Edit at the top right using only the keyboard (Tab to it and press Enter) and keep pressing Tab.Expect: There are no per-field Edit links. The top-right button reads Edit. Focus lands in the first editable field, and Tab moves through every field you may edit, including custom fields. Double-clicking a field still opens it for editing. Select Cancel.
SIS-352 View Data: From a data validation issue whose rule fails on Reporting language (for example Invalid Reporting Language, AERIES-025), select View Data on the record.Expect: The Demographics page opens and, once it has loaded, outlines the failing fields and puts focus on Reporting lang., the one you can edit, not on Language fluency. Pressing Enter opens it for editing. Select Cancel.
SIS-352 codes: Look at Reporting lang. and Correspondence lang., then select Edit and open the Reporting lang. picker. Cancel without saving.Expect: Both read code first, for example 01 - Spanish, and the picker options read the same way. Language fluency, Education level and the attendance programs show the description with the code in brackets, and Gender and Race show descriptions, also for a user who cannot edit them. A stored code that is no longer active is listed first, marked (inactive).
SIS-352 pins: Pin a field and a custom field, scroll down, then select Unpin on one of them in Pinned fields.Expect: The page scrolls back to that field where it normally sits and outlines it in blue for a few seconds.
SIS-352 Clear: Select Clear in the Pinned fields heading; choose Cancel, then select Clear again and choose OK.Expect: The question explains that pins are saved for you only, in this browser, and show on every student's page. Cancel keeps them. OK removes every pin and the Pinned fields card; open another student and no pins show there either.

Send lab feedbackupdated 2026-10-13

Open Feedback on any preview page, from the QA sidebar or from the minimized Lab QA control, crop and mark the shot, and write a note. Add several items as you move between pages, then submit them together.

Open the starting page →

Walkthrough unavailable for this build

Jira

SIS-113 Send lab feedback

Test as

Hosted admin (district-wide)

Build timeline

Build notes are not collected yet for this build.

QA walkthrough

Open the QA sidebar and click Feedback on a page containing lab/demo data only.Expect: The panel opens at once, about 80% of the window's width (more of a narrow window) and 90% of its height, with a placeholder, then shows what is on screen at the current scroll position, fitted, without screen-sharing permission. A window taller than 4:3 gives a 4:3 shot of its top portion. Student-name fields are masked in the shot. One line reads Submitting as your name and email; there is no name or email field.
Minimize the QA sidebar. Beside the Lab QA button, click Feedback (or Tab to it and press Enter). Write a note, then press Escape or submit and close.Expect: Feedback opens directly over the page: the QA sidebar stays minimized and the page keeps its full width, so the shot shows the whole page. Closing returns to the minimized control with focus on Feedback. Lab QA still expands the sidebar on its own.
Pick Arrow, Box, Text or Cover and drag on the shot. Drag Cover over some lab/demo text. Resize the window and draw again. Use Undo.Expect: Each mark starts and ends exactly under the pointer at any window size. Arrows, boxes and text are drawn heavy enough to read in a ticket. The toolbar reads Cover any real PII; Cover paints an opaque pixel-style mosaic and none of the text under it shows through. The shot does not zoom or move while you draw.
Draw a box, then pick Crop and drag a rectangle around part of the shot, in any direction (also past its edge). Click Undo crop, then crop again. Add the item, then Edit it.Expect: The crop is zoomed to fill the shot area; marks inside it stay where they were, marks outside it are left out. A tiny drag crops nothing. Undo removes marks only; Undo crop brings back the whole shot while the item is being written. After Add another (or Submit), the item keeps only the cropped part: on Edit, Undo crop is unavailable, and anything covered stays covered.
Write a note and click Add another. Close the panel, go to another page, click Feedback and add a second note. Edit one pending item, then remove one.Expect: Add another is the blue button beside the note (Tab from the note reaches it; Enter adds). It reads Save item while an item is being edited. The Feedback button shows the pending count. Pending items stay listed across pages with their own note and shot. Edit reopens an item with its marks; Remove drops it.
Click Submit.Expect: Every pending item, and the note being written, is sent as its own bundle under one submission. The panel says Sent only when the receiver returns a receipt for each item, and lists the receipts as links. The list empties.
Try submitting with an empty note.Expect: An empty note sends nothing.
Submit several items when the receiver is missing, signs you out, refuses, or answers without a receipt (on a preview with the demo receiver, any submit does this).Expect: A red Not sent notice takes focus at the top of the panel, at phone and desktop widths. It gives the reason, how many items the receiver confirmed and how many are not sent. It never says sent or thank you. The note you were writing is back in the editor with its shot and marks, the unsent items stay listed, and the Feedback button reads not sent.
Close the panel, go to another page, open Feedback and click Retry.Expect: The unsent items and the Not sent notice are still there. Retry sends only the unsent items under the same submission; confirmed items are not sent again.
If browser capture fails, click Try screen capture and deny permission.Expect: The fallback asks permission only after your click. Capture failure or permission denial allows submission without a screenshot and shows a visible notice. Granting permission captures one frame and stops sharing.

SIS-99 / F12: Browse system and custom rulesupdated 2026-10-13

One searchable table combines Aeries, district custom and CALPADS rules. A single filter row, matching the dashboard issue list, offers search, Type (Aeries, CALPADS, Custom), Category, Enabled (including retired references) and Provenance (Pete starter or Aeries lab). Each rule is one readable row: code and name, Source, Category, one status badge and the severity the district set. A click anywhere on a row opens or closes it, and several rows can be open at once. Each open row has one header (rule number, severity and state, with Edit, History and the on/off switch), then Description, Why this rule exists and How to fix it, with Advanced SQL. Verified shared catalogue identities appear once; distinct district instances remain separate. Starter activation is unavailable here. PR-only: native Windows and signed-in PR-head acceptance remain pending. Oct 11: Advanced: View SQL is a disclosure heading with a chevron; Copy SQL is a standard outline button with a brief Copied! confirmation and copies the stored SQL exactly. Oct 11 (SIS-264): no rule of any kind shows a filled light-blue panel in its open row. What a rule checks is ordinary text under the heading What this rule checks; a reference entry, or an entry with no lines, shows only its note. The blue edge down the left of the open row stays. Oct 12 (SIS-323): Enable Selected is hidden whenever the filtered table has no rules (a search or filter with no matches, while loading, or after a load error) and shown, still disabled, when rules are listed. Oct 13 (SIS-358): Advanced: View SQL shows the SQL formatted for reading, with each clause on its own line, indented conditions, CASE branches and subqueries, and coloured keywords, text values, numbers, names and comments. It is display only: Copy SQL still copies the stored text exactly, and nothing is saved or run.

Open the starting page →

Walkthrough unavailable for this build

Jira

SIS-99 Browse system and custom rules

Test as

Hosted admin (district-wide)

Build timeline

Build notes are not collected yet for this build.

QA walkthrough

Sign in with the lab/demo account and open Data Validation (beta) > Rule Browser.Expect: One rule table under one filter row: search, Type, Category, Enabled, Provenance, then the result count. No tabs, no boxed checkbox groups. The button at the top right reads Add Custom Rule and opens the rule builder. Counts include every cursor page. Type shows how many rules each choice lists; CALPADS covers the 41-entry reference inventory plus any state rules already in the district's list.
Type a code or title in search, then choose CALPADS under Type, a Category, and Not enabled under Enabled.Expect: Search narrows the loaded rows as you type, with no reload. All filters combine. CALPADS shows the reference entries that used to be on the Starter Library tab, once each, and the count beside the filters matches the number in the Type choice. A rule that is both an Aeries check and a CALPADS entry is listed under both types but is one row. Not enabled includes disabled rules and reference entries that have not been enabled, so no rule is missing from both choices.
Read down the table without opening anything, at desktop width and on a phone-width window.Expect: Each rule is one row: code and name; Source and Category in their own columns; one status badge (Enabled, Disabled, Template, Reference or Retired); and the severity exactly as the district set it, or a dash / 'No severity' when none is set, never a made-up value. A CALPADS entry's Source reads exactly CALPADS, with no Aeries lab or Pete starter text after it. There is no Guidance column. No rule numbers in the row. On a phone each rule is a card and nothing needs sideways scrolling.
Under Provenance choose Pete starter, then Aeries lab. Under Enabled choose Retired references. Then use Clear filters.Expect: Provenance is a visible choice in the filter row: 25 Pete identities and 41 Aeries lab catalogue identities, each count shown in the list; tags survive shared identity reconciliation. Retired references lists only entries CALPADS has retired. Old links (?provenance=, ?source=Pete%20starter, ?lifecycle=retired) select the same choices. A category or status that only an old link can set appears as a removable 'Also filtered by' chip. Distinct district rules are retained even when codes/titles match.
Click the Category or Status cell of a collapsed system rule, not its name. Then click the same row again.Expect: A click anywhere on the row opens it; a click on the open row closes it. The rule name is still a button: Tab to it and press Enter or Space to open and close the row, once per press.
Open one rule, then a second and a third. Close the middle one. Copy the address and open it in a new tab. Back in the first tab, choose a filter or go to the next page, then press Back.Expect: Each row stays open until you close it, and closing one leaves the others open. The page does not jump when a row opens, and keyboard focus stays on the rule name you used. The address names the row opened last that is still open; the new tab opens only that row. A filter, a search or a page change closes every open row, so none stays open out of sight; Back brings the open rows back. Edit, History and the on/off switch work as before in every open row.
Open a system rule, such as an Info rule, and read the open row from the top.Expect: One header, rule number first, for example "Rule #41 - Info - System-owned; cannot be disabled here". History sits just left of the on/off switch on that line; the switch is locked for a system rule. Below it, in order: Description, What this rule checks, Why this rule exists, How to fix it. None of them sits in a coloured box. Their paragraphs are one size smaller than before and the headings are unchanged. The text is the same size in the full-screen app (/app#/rules) and inside classic Aeries (DataValidationV6.aspx#/rules): open the same rule in both and compare. The detail lines up with the row above, with no second indent, and one blue edge runs down the left of the row and its whole detail.
In the open row, click History and close it, click the locked switch, and click the guidance text. Then open a custom rule and use Edit and its switch.Expect: Each control does only its own job: History opens the history, the locked switch does nothing, the custom rule's switch saves, Edit opens the rule builder. None of them closes the row, and clicking text inside the detail does not close it either.
Open a custom guidance gap, a service-copy template and a retired CALPADS reference. Then choose Pete starter under Provenance.Expect: The open row carries the detail: what the rule checks as plain text (custom rule and template only), inherited why/how and the exact Guidance pending review state where guidance is missing or awaiting review. A CALPADS entry's header starts with its code, and its Aeries lab / Pete starter tags are shown in the detail. The Provenance filter still lists the same rules as before. SQL loads only from Advanced for permitted readers. CDE source links, retired restrictions and system toggle locks remain intact.
SIS-264: open a Reference or Retired CALPADS entry, then a Template (for example SERV0410E1), then an Aeries rule (for example AERIES001) and a custom rule.Expect: No open row has a filled light-blue panel, and none has empty space where it was. The reference entry shows its tags and source line, then one small grey line saying why it does not run, followed by its approved source note when it has one, then Why this rule exists and How to fix it. The Template shows its IF / THEN lines as ordinary text under What this rule checks, with its small grey note underneath. The Aeries and custom rules show their summary or lines the same way, as ordinary text under What this rule checks; Advanced: View SQL still opens the SQL in a grey code box. Each open row keeps the blue edge down its left side. In the full-screen app (/app#/rules) the bold heading at the top of each open row, for example "Rule #1 - No severity - System-owned; cannot be disabled here", has clear gaps between its words.
Open a rule and look for History. Then use only the keyboard: Tab to History, press Enter, press Escape.Expect: History is not on the collapsed row. It sits in the open rule's header, just left of the on/off switch, for system and custom rules. Enter opens the same rule history as before; Escape, Close or clicking outside closes it and focus returns to History.
Search SENR0269F1 in the combined rule table and expand its row.Expect: The small grey line under the source gives the reason it does not run, then the approved LOC.LO / LOC.HI source note. Why this rule exists and How to fix it stay separate below. The draft has no selection checkbox or Enable action; Description only remains disabled.
Review Enable Selected and a reference row.Expect: Enable Selected is shown, and disabled, only while the table lists at least one rule. A Template says it needs a test-run and approval; Reference and Retired rows never become executable. No starter activation or CALPADS parity claim.
SIS-323: search for ZZ Pete Test Rule, then clear it and search SENR, then choose a Type.Expect: With no matching rules the table says no rules match, the count reads 0 of the total, and Enable Selected is not on the page. With matching rules it is back, still disabled, and nothing is turned on.
Choose a Type, go to the next page, open a row and use Back/Forward; open an old /rules/starter-library?source=Pete%20starter&ruleCode=SENR0269F1 link.Expect: URL restores filters/page/row. Old starter links redirect to /rules with CALPADS selected and the requested row open; one Back leaves the page rather than bouncing. A search is one Back step, not one per keystroke. Searching resets to page one.
Search for a missing term; exercise delayed and failed API responses in the local browser harness.Expect: Clear empty/loading/error states; Retry loads both lists. While rules load, the title, Add Custom Rule and filter row stay in place and no earlier rows or count are shown. Partial or failed cursor pages do not publish misleading counts.
F14, dv6-next only, after preview operations has run the seed: open Rules and expand AERIES006 (Date of Birth missing).Expect: Under What this rule checks the row shows "Finds students with no birth date." and a second line about which student records are checked, followed by the small marker "Drafted from SQL, not yet reviewed". It no longer says the plain-language summary needs review.
F14: in the same row, focus Advanced: View SQL with Tab and press Enter. Click Copy SQL and paste into a scratch text field. Press Space on the heading.Expect: Advanced: View SQL reads as a heading with a chevron that points right when closed and down when open. The SQL loads below the lines, formatted for reading (SIS-358): SELECT, FROM, WHERE and each JOIN start their own lines; list items, AND / OR conditions, CASE branches and subqueries are indented; keywords, quoted text, numbers, bracketed names and comments are coloured. A small grey line beside Copy SQL reads "Formatted for reading. Copy SQL copies the stored text exactly." Copy SQL is an outline button; a small Copied! appears beside it and clears, and the pasted text is the stored SQL exactly, including its original whitespace. Space closes the section and removes the SQL from the page. Why this rule exists and How to fix it are unchanged.
F14: expand AERIES005 (Missing CDS Code).Expect: It still shows its reviewed Condition, Scope and Result summary, with no draft marker.
F14: open Rules on any preview where the seed has not run and expand a rule.Expect: The row is unchanged: rules without a verified summary still say the plain-language summary needs review, and nothing fails.
Classic screens: in Rule Browser, switch a custom rule off. Straight away, in another tab, open School Info > Data Validation > Data Validation Definitions and find that rule.Expect: The classic list already shows the rule as disabled. There is no wait of several minutes for the change to appear.
Classic screens: on Data Validation Definitions, edit a rule's description and save, then use Test on its query with a deliberate SQL error.Expect: Both behave as in current Aeries: the save succeeds and the list updates, and the test reports the actual SQL error text.
Classic screens: open School Info > Data Validation > Data Validation Results.Expect: The results are grouped as in current Aeries. Issues of a rule that is switched off are not listed, and no result appears twice.

Navigate the lab QA experienceupdated 2026-10-11

The preview review panel shows this round’s name, full database name, Jira items and a guide for this build. Try opening the guide and a feature’s Jira item; a missing guide is explained plainly.

Open the starting page →

Walkthrough unavailable for this build

Jira

SIS-183 Navigate the lab QA experience

Test as

Hosted admin (district-wide)

Build timeline

Build notes are not collected yet for this build.

QA walkthrough

Open /LabQaHome.aspx on the lab preview.Expect: A navy Aeries hero with the white Aeries logo, a red LAB PREVIEW badge, and tiles for target, database, build and commit that match /coder-preview.json.
Look at Lab environments.Expect: DV6 integration, Babelfish lab and SQL Server lab are listed. The one you are on has a green 'You are here' chip and a green top edge.
Hover a card under What's in this build.Expect: The card lifts with a blue-to-sky bar along its top. Each card shows when it was updated, its number of steps and the demo accounts to use.
Click Start walkthrough on 'Navigate the lab QA experience'.Expect: The sign-in page opens with the QA panel focused on this Story. The Story starts on /LabQaHome.aspx.
Back on the home page, scroll to Demo accounts.Expect: The lab/demo accounts with their roles. No passwords anywhere on the page.
Open the page on a phone-sized window.Expect: One column, no sideways scrolling, buttons still easy to tap.
Open the same build under any non-lab host name.Expect: /LabQaHome.aspx answers 404 and no landing content appears.
Open the lab preview's /Login.aspx.Expect: The Lab QA panel is open on the left. The top row is one line: a PREVIEW badge, Feedback and a plain X. Below the title, one compact row shows the commit and database from /coder-preview.json (hover a truncated value for the full text; there are no Build or Target tiles and no lab/demo note). The header uses the Aeries navy-to-blue gradient and headings use Aeries Sans.
Tab to Open full-screen walkthrough near the top of the panel, on login and after signing in. Also check /LabQaHome.aspx.Expect: For a published exact-build artifact, Enter opens that build’s narrated slideshow in a new tab. An unpublished, unreadable or invalid build shows plain Walkthrough not published yet text with no link, in white on the navy header so it is easy to read on every host page (it is part of the panel, so it is not shown while the panel is minimized); another job’s slideshow is never offered.
Click the 'admin' account under Suggested lab accounts.Expect: The username box is filled with admin and the cursor moves to Password. No password is filled. The admin card is highlighted with a green avatar, and a status note in the header confirms the fill.
Expand any feature.Expect: The starting page is a small secondary link. Exactly one SIS Jira link is listed and opens in a new tab. Each Story also shows Watch walkthrough for this job or plain unavailable text.
In an expanded feature, read Build timeline.Expect: The builds of this preview that changed this Story, newest first. Each row shows the build's UTC cut time, its short commit and one plain sentence for each change first included in that build. A Story no collected build changed says No build notes for this Story yet. When no notes were collected for the running build, it says Build notes are not collected yet for this build and shows no rows.
Type 'dispute' in Filter features, then type a word that matches nothing.Expect: Only the matching walkthroughs stay listed. With no match, a 'No walkthroughs match this filter' note appears instead of an empty list.
Click the X (Hide QA sidebar), then sign in.Expect: The panel slides away to a navy 'Lab QA' pill in the bottom-left corner with a coral dot and the number of features in this build. It stays collapsed on signed-in pages until you open it.
Drag the thin handle on the panel's right edge, or Tab to it and use Left/Right (Shift for larger steps), Home and End. Reload the page.Expect: The panel resizes between 320 and 720 px, never wider than the window, and the chosen width is restored after the reload. Double-click the handle to return to the default.
Open the same build on any non-lab host name (e.g. a customer district URL or the server's IP).Expect: No sidebar, no Lab QA tab and no sidebar CSS/JS in the page source.

Open Data Validationsupdated 2026-10-11

School Info > Data Validation (beta) opens Data Validations inside Aeries (/DataValidationV6.aspx), with the usual Aeries menu and header around it. Open full screen moves the same page to /app, the chromeless app with its own navy sidebar, and Back to Aeries returns to the same page inside Aeries. Links clicked inside either view stay in that view; a pasted /app link stays full screen. Dashboard, Rule Browser, Field Mapping, issue and student hash routes survive refresh and Back in both. The former /DataValidationV6App.aspx entry redirects to /app with query values and browser-inherited fragments. The same 13 Stories, sidebar and walkthrough mappings remain. The existing What's new dialog and record actions are unchanged.

Open the starting page →

Walkthrough unavailable for this build

Jira

SIS-94 Open Data Validations

Test as

Hosted admin (district-wide)
Teacher
Hosted admin (district-wide)

Build timeline

Build notes are not collected yet for this build.

QA walkthrough

Sign in as admin, open School Info in the left navigation and expand Data Validation (beta).Expect: Three children, in order: Dashboard, Rule Browser and Field Mapping.
Type 'Data Validation' in the navigation filter.Expect: Both Data Validation (beta) entries are found.
Click Dashboard, then Rule Browser.Expect: The address is /DataValidationV6.aspx#/dashboard. The dashboard stat row and issue list render inside the normal Aeries layout, with the Aeries menu and header still showing, then the Rule Browser opens to the rule list in the same layout.
Paste /app#/rules into a fresh tab.Expect: The Rule Browser loads directly, not the dashboard.
At 1440px wide, scroll the dashboard and open and collapse the Aeries menu.Expect: The issue list fits the content area beside the Aeries menu, with no horizontal scrollbar.
From the dashboard inside Aeries, open an issue, then use its breadcrumb and View Data links to other Data Validations pages.Expect: Every page opens inside Aeries: the Aeries menu and header never disappear and the address stays on /DataValidationV6.aspx.
On that issue, click Open full screen (beside What's new).Expect: The same issue opens at /app with the navy DV6 sidebar and no Aeries menu or header. Refreshing keeps it full screen.
Click Back to Aeries at the bottom of the navy sidebar, then use browser Back and Forward.Expect: The same issue returns inside Aeries. Back and Forward move between the two views without changing the page shown.
Sign out and sign in as teacher.Expect: Data Validation (beta) is not offered: it is a staff/admin tool.
Open /app.Expect: The dashboard renders with the DV6 sidebar and no SIS navigation or top bar.
Use the sidebar to go to Rule Browser, Field Mapping and a coming-soon page.Expect: Each renders inside the same shell, with Data Validations above one page title and no separate title bar. The left menu has no Assistant entry; the round Assistant button at the bottom right is the only way in, and it opens the Assistant without changing the page or the highlighted menu item.
Load /app#/rules in a fresh tab.Expect: The Rule Browser loads directly.
On the Rule Browser (46+ rules), scroll down.Expect: Only the content scrolls. The sidebar footer stays visible.
Acknowledge a record on an issue.Expect: The existing server result and badge.
Sign in with an account that has not opened DV6 since this build (the automated suite marks it seen for admin, so try sysadmin) and open Data Validation (beta) > Dashboard.Expect: The "What's new in Data Validations" dialog opens by itself on the first slide, with Next focused and no Back button.
Look at the size of the dialog on a normal desktop window, then on a small laptop-height window or a narrow one.Expect: On a desktop it is about 960 px wide and the screenshot fills its width, so text in the picture can be read. On a smaller screen it keeps a margin on every side, the picture shrinks to fit, and the title and Next button stay visible without scrolling.
Step through every slide with Next, try Back and the dots.Expect: Each slide has a title, text and picture, with 'Slide N of M'. The last button reads Continue.
Find the "Ask the assistant about an issue" slide (added in intro version 2, so anyone who saw version 1 sees the intro again once).Expect: Its picture shows the assistant drawer answering a "Help me fix" starter on an issue, with student names blanked.
Click Continue, then reload the page and open the full-screen app (/app).Expect: The intro does not open again after reload or canonical app entry.
Click the What's new button.Expect: The intro reopens on the first slide.
Turn on reduced motion in the OS or browser and open it again.Expect: Slides change without animation.
Open /DataValidationV6App.aspx?schoolYear=2026#/rules. Refresh and use Back.Expect: It redirects once to /app, retains the query and hash route, and displays the chromeless shell.
Signed out, open /app?schoolYear=2026 and complete the configured SSO login.Expect: Login returns to /app with schoolYear=2026, rather than a report page or redirect loop. A fragment may be lost across the external IdP; it is not sent to the server.
Sign in separately as parent and student and open /app, /DataValidationV6.aspx and /DataValidationV6App.aspx.Expect: Each redirects to the classic Default.aspx page without rendering DV6 bootstrap or data.
Look for a small "Build xxxxxxxx" line: at the bottom right of the page under the content when inside Aeries, and in the left menu just above Back to Aeries in full screen, where it stays clear of the Lab QA button in the corner. Click it.Expect: The text briefly changes to Copied and the full build ID is on your clipboard. The eight characters match the start of the build named in the ready note, and the line is the same on every page, in both views.
Open /app?schoolYear=2026#/rules and use Back to Aeries.Expect: The Rule Browser reopens inside Aeries at /DataValidationV6.aspx?schoolYear=2026#/rules, with the Aeries menu and header back. Browser Back returns to the full-screen Rule Browser.
Inside Aeries with the Aeries menu open, on the Dashboard and then the Rule Browser, drag the browser window narrower than a tablet (or switch a wide window to a 390px phone view without reloading).Expect: The Aeries menu closes itself and the page stays readable from its left edge: Data Validations, the title, the filters and the count are complete, and nothing scrolls sideways. Tab still moves through the page's controls. The Aeries menu button still opens the menu, and widening the window brings the menu back beside the page.

Run a CALPADS practice runupdated 2026-10-11

Run a CALPADS practice check before submission and review its errors on the dashboard. The Certification card now counts down to the next official CALPADS certification deadline only from a reviewed copy of the CDE calendar, labeled with its source and school year, and shows the district's own ready-by milestones separately (SIS-147). Desktop width only this round.

Open the starting page →

Walkthrough unavailable for this build

Jira

SIS-104 Run a CALPADS practice run

Test as

Hosted admin (district-wide)
Staff user

Build timeline

Build notes are not collected yet for this build.

QA walkthrough

On the dashboard at desktop width, look at the Certification card.Expect: Until a named reviewer signs the CDE comparison (this build ships without one): 'Dates unavailable' and 'No reviewed CDE calendar for 2026–27', with no date from anywhere else. After sign-off: a day count, then 'State: Fall 1 certification Dec 11 · CDE 2026–27'.
Open the card.Expect: 'CALPADS calendar · 2026–27'. State deadlines are marked 'Read-only · set by CDE' with a link to the CDE CALPADS Calendar and its review status. Each window shows the state deadline on the left and district ready-by milestones on the right. A note says the dates are California calendar days.
As a user with State Reporting Admin, choose Add milestone on Fall 1, enter a name and a date before the state deadline, and save. Reload the page and open the card again.Expect: The milestone appears in Fall 1's district column and on the card as 'District: <name> by <date>'. The state deadline beside it has not changed.
As a user with State Reporting Admin, try a ready-by date after Fall 1's state deadline, or a name containing 'certification deadline'.Expect: The server's reason shows under the form and nothing is saved.
As a user with State Reporting Admin, edit the milestone, then remove it.Expect: Each change shows at once and survives a reload. Removing asks for confirmation and leaves the state dates alone.
Sign in as an account without Admin permission on State Reporting (the classic CALPADS Extracts permission) and open the card.Expect: Milestones are visible but there is no Add, Edit or Remove. A direct API write is refused with the server's permission message (403). The controls are shown only to an account that can actually save: a State Reporting Admin without live Data Validations access (for example a teacher account) sees no Add, Edit or Remove either.
As admin (System Administrator), click Run now in the practice run section.Expect: 'Practice run queued. Refresh the list in a few minutes.' The panel shows it running.
Refresh after a few minutes.Expect: CALPADS issues appear with their CALPADS codes and deadlines.
Open the Rule Browser and find a CALPADS rule.Expect: It is tagged CALPADS (state) and locked.
Sign in as an account without Data Validation admin rights and click Run now.Expect: The server's permission message shows (403). Nothing is queued.

SIS-97: Why this rule exists and How to fix itupdated 2026-10-11

SIS-97: the same source-authored purpose and concrete next step in the rule browser, finding detail and assistant context. Missing guidance and unreviewed drafts stay conspicuous. New custom activation requires both fields. Review-only PR; signed-in deployed acceptance remains pending integration.

Open the starting page →

Walkthrough unavailable for this build

Jira

SIS-97 Read rule explanations

Test as

Hosted admin (district-wide)

Build timeline

Build notes are not collected yet for this build.

QA walkthrough

Open AERIES032 in the rule browser and its finding detail.Expect: Both show the same Why this rule exists and How to fix it. Existing key/page links, severity and year context remain intact. On the finding, the why/how text is the same size as the problem description above it, in the full-screen app (/app#/dashboard/issues/<id>) and inside classic Aeries alike.
Open the executable SERV0410E1 starter and a CDE reference or retired STAS0313 entry.Expect: The service-copy check has sourced guidance. The panel is Why this rule exists and How to fix it only: no Source documentation link, no Guidance source or provenance row, and no link to a source repository on a system, service-copy, extract or custom rule. Missing CDE guidance remains Guidance pending review; retired/reference entries do not become executable.
Open a custom rule with missing guidance.Expect: The open row shows Guidance pending review above the why/how text (the list no longer has a Guidance column); the owner/admin has an Edit action or the classic definitions edit path. Re-enabling without guidance stays refused, shows an actionable message and expands the owner edit path. Read permission does not grant edit permission.
Create a custom draft, run its test, leave either guidance field blank, then try to activate.Expect: Activation is unavailable; direct API activation returns guidance_required with both field names. An inactive draft may still be saved.
Enter the custom purpose and a concrete next step, activate after a successful test, and ask the assistant why the finding is flagged.Expect: The browser, finding and authenticated assistant read use identical guidance and provenance. Drafts name Pete for CALPADS review; missing guidance is never invented.

Manage field mappingsupdated 2026-10-10

Field mappings show how CALPADS fields match Aeries fields. Try reviewing a suggested match and changing a permitted mapping, then check whether rules using it are marked for review. Oct 10: Field Mapping and Custom Fields are now built from the shared form kit; a lab-only gallery at /app#/lab/form-kit shows every control state.

Open the starting page →

Walkthrough unavailable for this build

Jira

SIS-101 Manage field mappings

Test as

Hosted admin (district-wide)

Build timeline

Build notes are not collected yet for this build.

QA walkthrough

In the classic menu, open School Info > Data Validation (beta) > Field Mapping.Expect: Field Mapping sits below Dashboard and Rule Browser and opens at /app#/field-mapping in the chromeless DV6 shell.
Open /app#/field-mapping.Expect: The content has padding on the left and right, and the title appears once. The catalog lists Aeries-suggested fields with CALPADS IDs and Aeries columns, and shows suggested and confirmed counts.
Open a suggested field.Expect: It carries the note: an Aeries suggestion, not a guarantee.
Click Add Field Mapping, fill it in and save.Expect: It is added as confirmed, with the note that your district owns keeping it accurate.
Change the custom field's column.Expect: Exactly the rules that used it are flagged '1 rule to review'. 'Mark reviewed' clears the flag.
Remove the custom field (click Remove field twice).Expect: It is gone. Seeded fields cannot be removed.
At 1440px, inspect Field Mapping at /app#/field-mapping in the chromeless shell, then open Add Field Mapping and Edit.Expect: The standard title is at the top; Add Field Mapping and What’s new share a right edge. Instructions use the available width, the right grid gutter is 14px, Category carets are small gray triangles. The existing catalog behavior is unchanged; its future role under SQL-only authoring awaits Jesse’s product decision.
Look at the last column of the Field Mapping table, then press Tab until a row action is focused and press Enter.Expect: Review & Confirm and Edit are bold blue text links with no button outline. The focused link shows a ring, and Enter opens its dialog.
Open Review & Confirm on a suggested field, then Cancel and click Add Field Mapping.Expect: In both dialogs the text in CALPADS field ID, Field name and Aeries column starts a little in from the left border, the same as the Category dropdown and the Note box.
Narrow the browser to a phone width (about 390px) on /app#/field-mapping and try to scroll sideways.Expect: Each mapping is a stacked block: name, then category, Aeries column and status, then Confirmed by with Review & Confirm or Edit at the right. The page does not scroll sideways and the page title stays in place. At desktop width it is the same table as before.
Open Add Field Mapping, then press Tab several times and then Escape. Open it again and look at the Add field button before typing anything.Expect: Focus starts in Category and Tab stays inside the dialog. Escape closes it and focus returns to the button that opened it. Add field is faded until the form can be sent. Every box is the same height, with the same padding and the same blue focus ring.
Form kit gallery (lab only): open /app#/lab/form-kit.Expect: One page lists every shared form control, each in its states: empty, filled, with help, required, focus, error, disabled, read-only and 390px. Demo wording only: nothing there reads or saves a record.
Use the links at the top to open one component, for example Select.Expect: The address becomes /app#/lab/form-kit/select and only that component is shown. All components brings the full page back.
Press Tab through the controls on the Text input page.Expect: Each control shows the same blue focus ring. Disabled controls are skipped; read-only ones take focus but cannot be changed.
On the Toggle page, focus a toggle and press Space. Try the read-only one too.Expect: The toggle switches on and off. The read-only toggle stays as it is.
Narrow the window to about 390px.Expect: Controls take the full width, form rows stack one field per line, buttons wrap, and nothing scrolls sideways.
Open /app#/custom-fields as an administrator and click Add Custom Field.Expect: The form uses the same boxes, labels and buttons as the gallery and as the Field Mapping dialog. Labels, saving and permissions are unchanged.
Open /app#/field-mapping; refresh and return with Back.Expect: The hash route remains correct in the chromeless DV6 shell; existing filters, permissions and record actions are unchanged.

Build and test a custom ruleupdated 2026-10-09

Create a custom rule with the step-by-step builder and test it before activation. Try choosing a field and condition, review the written explanation, and check the sample results before saving.

Open the starting page →

Walkthrough unavailable for this build

Jira

SIS-100 Build and test a custom rule

Test as

Hosted admin (district-wide)

Build timeline

Build notes are not collected yet for this build.

QA walkthrough

Rule Browser > Create Custom Rule.Expect: Step 1 (Domain) opens. Next stays disabled until a choice is made, with a hint saying why.
Pick a domain, then a field (e.g. a student field) and a condition.Expect: The rule is shown as a sentence. 'Show the SQL' reveals the generated SQL.
Go Back one step and forward again.Expect: Your answers are kept.
On Test & Activate, click Run test.Expect: Flagged count and percentage of the records checked. 'Show the flagged records' lists them.
Make a rule that flags most students (e.g. a field is not missing) and run the test.Expect: An over-broad warning. Activation needs the records reviewed and then 'Activate anyway'.
Fill in name, group and severity and save, leaving it not activated.Expect: Saved. The rule shows in the Rule Browser as custom and inactive.
From the Rule Browser, click Edit on that rule.Expect: It reopens in the builder. Rules built elsewhere cannot be edited here: the button is disabled with a reason.
Deactivate the test rule when you are done.Expect: The lab is left as you found it.
Create Custom Rule. Build a draft that matches an existing active rule exactly and click Run test.Expect: A duplicate warning names the existing rule.
Narrow the draft so that another active rule already covers it, then test again.Expect: A redundant/overlap warning names the covering rule.
Build a draft whose condition contradicts an active rule on the same field, then test.Expect: A conflict warning.
Build an unrelated draft and test.Expect: 'No active rule duplicates, conflicts with or overlaps this one.'
Leave the builder without saving.Expect: Nothing is saved.