Skip to content

Say which class a text came from, and which texts a class hides - #719

Merged
mircealungu merged 2 commits into
masterfrom
wt/class-attribution
Aug 31, 2026
Merged

Say which class a text came from, and which texts a class hides#719
mircealungu merged 2 commits into
masterfrom
wt/class-attribution

Conversation

@mircealungu

Copy link
Copy Markdown
Member

Two halves of the same gap, found when our pilot teacher asked whether he had to leave one class in order to see another's texts. He didn't — but nothing in the app told him so, because a student's classroom is a merged list with no provenance.

cohort_articles_for_user tags each text with its class

from_classes: [{id, name}] per article. A text shared with two of the student's classes still appears once, naming both. The client shows the tag only to a student who has more than one class (zeeguu/web#PENDING).

/cohort_text_overview reports its texts' languages again

Nothing stops a text in another language being shared with a class, and its students then never see it — they only ever get the texts in the language they're learning.

Checked against production:

Classes holding texts in more than one language 7 (6 with two, 1 with three)
Texts in those classes 32
Students with class texts they cannot open 54
…of whom active since June 0

So it's latent rather than burning — but it is silent in both directions today. The teacher is the only person who can fix it, so the count goes to them (on the class Texts tab) rather than to the students, whose only "fix" would be to switch out of the language they chose.

Tests

3 new (test_cohort_article_attribution.py), covering the tag, a text in two of the student's classes appearing once with both names, and off-language texts still being filtered out.

Deploy before the web side; without it from_classes is absent and the tag simply doesn't render.

Two halves of the same gap, found when our pilot teacher asked whether he had
to leave one class in order to see another's texts. He did not -- but nothing
in the app told him that, because a student's classroom is a merged list with
no provenance.

- cohort_articles_for_user tags each text with the classes it came from. A
  text shared with two of the student's classes still appears once, naming
  both. The client shows the tag only to a student who has more than one class.

- /cohort_text_overview reports the languages its texts are in again. Nothing
  stops a text in another language being shared with a class, and its students
  then never see it: they only ever get the texts in the language they are
  learning. Seven classes are in that state today, holding 32 texts between
  them, and 54 students have texts in their class they cannot open. The
  teacher is the one who can fix it, so the count goes to them rather than to
  the students.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

ArchLens - No architecturally relevant changes to the existing views

get_cohort_info stringified it, alone among the endpoints that carry a cohort
id -- Article's `shared_with` and the classroom's `from_classes` both send an
int. So the same class arrived with two different identifiers depending on
which endpoint you asked, and code that matched one against the other silently
matched nothing.

That was not hypothetical: the share dialog builds its {id, name} objects from
/cohorts_info while a reloaded texts list gets them from /teacher_texts, so a
class shared during a session and the same class after a refresh produced two
separate filter chips.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@mircealungu
mircealungu merged commit 2c0b713 into master Aug 31, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant