Skip to content

Overhaul School Vocabulary Manager - #9608

Open
michaelchadwick wants to merge 1 commit into
ilios:masterfrom
michaelchadwick:frontend-6927-school-vocab-manager-overhaul
Open

michaelchadwick wants to merge 1 commit into
ilios:masterfrom
michaelchadwick:frontend-6927-school-vocab-manager-overhaul

Conversation

@michaelchadwick

Copy link
Copy Markdown
Contributor

Fixes ilios/ilios#6927

The current School Vocabulary Manager needed an overhaul and that's what this PR does.

  • Change the view of terms to use the same tree-style view as the TaxonomyManager used when adding terms to Courses, Sessions, etc.
  • Top-level terms are still added using the conventional form but it is now hidden behind a toggle
  • Move the forms for adding and editing terms into the list item
  • Added Ilios-standard deletion trash can and confirmation protection
  • Could not find a better icon to indicate "add sub-term", so + will have to do for now
  • Full suite of integration tests
  • Claude helped with the initial push to get stuff going, but plenty of manual changes were done by this human, and most code was probably updated or expanded since then

The Taxonomy Manager could probably use some updates, like adding term counts, but that's a separate PR.

Old
Screenshot 2026-10-07 at 5 49 22 PM

Bold
Screenshot 2026-10-07 at 5 49 17 PM

@netlify

netlify Bot commented Oct 8, 2026 •

Copy link
Copy Markdown

✅ Deploy Preview for ilios-frontend ready!

Name Link
🔨 Latest commit dab366b
🔍 Latest deploy log https://app.netlify.com/projects/ilios-frontend/deploys/6ad2b2e39572266f24508e64
😎 Deploy Preview https://deploy-preview-9608--ilios-frontend.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
🤖 Make changes Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

@github-actions

github-actions Bot commented Oct 8, 2026 •

Copy link
Copy Markdown
Contributor

✅ Visual Diff Report — PASSED

2264 images compared: 104 added · 2160 identical

Details

Added Files (104)

  • desktop-Acceptance _ School - Vocabulary Manager_add new vocabulary sub-term_edit term form_dark.png
  • desktop-Acceptance _ School - Vocabulary Manager_add new vocabulary sub-term_edit term form_light.png
  • desktop-Acceptance _ School - Vocabulary Manager_add new vocabulary sub-term_new sub-term form_dark.png
  • desktop-Acceptance _ School - Vocabulary Manager_add new vocabulary sub-term_new sub-term form_light.png
  • desktop-Acceptance _ School - Vocabulary Manager_add new vocabulary sub-term_post-save_dark.png
  • desktop-Acceptance _ School - Vocabulary Manager_add new vocabulary sub-term_post-save_light.png
  • desktop-Acceptance _ School - Vocabulary Manager_add new vocabulary top-level term_new top-level term form_dark.png
  • desktop-Acceptance _ School - Vocabulary Manager_add new vocabulary top-level term_new top-level term form_light.png
  • desktop-Acceptance _ School - Vocabulary Manager_add new vocabulary top-level term_post-save_dark.png
  • desktop-Acceptance _ School - Vocabulary Manager_add new vocabulary top-level term_post-save_light.png
  • desktop-Acceptance _ School - Vocabulary Manager_delete existing vocabulary term but cancel_edit term form_dark.png
  • desktop-Acceptance _ School - Vocabulary Manager_delete existing vocabulary term but cancel_edit term form_dark(1).png
  • desktop-Acceptance _ School - Vocabulary Manager_delete existing vocabulary term but cancel_edit term form_light.png
  • desktop-Acceptance _ School - Vocabulary Manager_delete existing vocabulary term but cancel_edit term form_light(1).png
  • desktop-Acceptance _ School - Vocabulary Manager_delete existing vocabulary term but cancel_post-cancel_dark.png
  • desktop-Acceptance _ School - Vocabulary Manager_delete existing vocabulary term but cancel_post-cancel_light.png
  • desktop-Acceptance _ School - Vocabulary Manager_delete existing vocabulary term_delete term form_dark.png
  • desktop-Acceptance _ School - Vocabulary Manager_delete existing vocabulary term_delete term form_light.png
  • desktop-Acceptance _ School - Vocabulary Manager_delete existing vocabulary term_edit term form_dark.png
  • desktop-Acceptance _ School - Vocabulary Manager_delete existing vocabulary term_edit term form_light.png
  • desktop-Acceptance _ School - Vocabulary Manager_delete existing vocabulary term_post-save_dark.png
  • desktop-Acceptance _ School - Vocabulary Manager_delete existing vocabulary term_post-save_light.png
  • desktop-Acceptance _ School - Vocabulary Manager_edit existing vocabulary term_edit term form_dark.png
  • desktop-Acceptance _ School - Vocabulary Manager_edit existing vocabulary term_edit term form_light.png
  • desktop-Acceptance _ School - Vocabulary Manager_edit existing vocabulary term_post-save_dark.png
  • … and 79 more

Download the results.

@michaelchadwick michaelchadwick added the approve visual diff Manually Approve the Results of a Visual Diff Run label Oct 8, 2026
@michaelchadwick
michaelchadwick force-pushed the frontend-6927-school-vocab-manager-overhaul branch from bebf909 to 6062c2e Compare October 8, 2026 16:10
@github-actions github-actions Bot removed the approve visual diff Manually Approve the Results of a Visual Diff Run label Oct 8, 2026
@saschaben

saschaben commented Oct 8, 2026 •

Copy link
Copy Markdown
Member

I'm liking the progress! Two quick notes after a cursory review:

First - can we get a "add new (top-level) term" tooltip for the big add (+) icon, similar to what we have for the individual sub-term add icons?
second - while we are on sub-terms...what if we were to move the add sub-term function to the edit screen of the term itself? I know we touched on top-level accessibility for this, but in this iteration I think it is clear that having the full display, along with the one-level edit tool, AND right next to it the add a sub-level tool, gets a bit busy and unintuitive. Moving the sub-term add into the term edit screen might make more intuitive sense now.

@michaelchadwick

Copy link
Copy Markdown
Contributor Author

Todo:

  • Remove "Title:"
  • Add tooltip to top-level term +
  • Move filter to right-side, make smaller
  • Clicking the highlighted row will trigger edit form
  • Hide new sub term icon unless in the edit form to de-emphasize it
  • Try making icons larger when in edit form mode

@michaelchadwick
michaelchadwick force-pushed the frontend-6927-school-vocab-manager-overhaul branch 8 times, most recently from 239b5a5 to a0d6c41 Compare October 15, 2026 21:04
@michaelchadwick
michaelchadwick marked this pull request as ready for review October 15, 2026 22:06
@michaelchadwick
michaelchadwick marked this pull request as draft October 15, 2026 22:07
@michaelchadwick
michaelchadwick force-pushed the frontend-6927-school-vocab-manager-overhaul branch from a0d6c41 to 479f9bc Compare October 16, 2026 17:20
vocabulary: this.args.vocabulary,
active: true,
active: isActive,
...(parent ? { parent } : {}),

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks weird to me, not sure why it is destructuring the parent if it's set. I guess it works, but

Suggested change
...(parent ? { parent } : {}),
parent: termParent ?? null,
// or
if (parent) {
term.parent = parent;
}

would be a little bit clearer IMO.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree it looks odd. I tried your suggestions, but it broke it. Investigating into it more.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just changing it like this was the simpler fix:

  ...
  parent,
});

Comment on lines +146 to +150
if (parent) {
const siblings = await parent.children;
siblings.splice(siblings.indexOf(term), 1);
parent.set('children', siblings);
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels a little bit like an old ember-data pattern. I don't think this is necessary anymore, and it might be possible to remove it entirely. If not let's get together and play with some options.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was unchanged code, btw, but you're right: it's not needed. I got rid of it, tests pass, and feature still seems to work.

);
}
<span class="actions">
{{#if @canUpdate}}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this ever be true? Doesn't seem like we'd want actions on the new term form.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is for the "Edit" icon to appear, so you can switch back to it.

My only reason for removing it would be because we assume that once you've gotten here from the "Edit Term" form that you obviously have @canUpdate permissions, so there's no need to check again. /shrug

}

get itemElement() {
return document.getElementById(this.itemId);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm ok with this, but I think a setElement = modifier((element) => this.itemElement = element); would be a little easier to grok. Then the itemId can go away as well.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this convention anywhere else in the codebase. Can you expand on how this would work?

export default class SchoolVocabularyTermsListComponent extends Component {
@cached
get termsData() {
if (this.args.terms !== undefined) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is confusing for me, as far as I can tell this component is only called in one place and the terms are always passed in.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sometimes there are no terms passed in because the filter prevents it.

Comment thread tests/acceptance/school/vocabularies-manager-test.js
assert.strictEqual(component.items[1].title, 'Zebra');
});

test('clicking list item does nothing if not permitted to update', async function (assert) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're also losing the tooltip when update isn't enabled. I think it should probably stick around.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added the tooltip and row highlighting back even when @canUpdate is false. Cursor does not turn into pointer and the toggling is still off, though.

Comment thread translations/en-us.yaml
durationInYears: Duration (in Years)
durationMinutes: "{count, plural, =1 {1 minute} other {# minutes}}"
edit: Edit
editSubTerm: Edit Sub-term

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need this split. It can always be Edit Term

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Team discussion in a previous meeting decided to split the strings up into "Edit Term" and "Edit Sub-term" so as to further disambiguate where in the tree of terms you're editing, so I think we should keep it.

Comment thread translations/en-us.yaml
newSchool: New School
newSession: New Session
newSessionType: New Session Type
newSubTerm: New Sub-term

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need this split. It can always be New Term

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Team discussion in a previous meeting decided to split the strings up into "New Term" and "New Sub-term" so as to further disambiguate where in the tree of terms you're adding, so I think we should keep it.

Comment thread app/components/school/new-vocabulary-form.gjs Outdated
@michaelchadwick
michaelchadwick force-pushed the frontend-6927-school-vocab-manager-overhaul branch 2 times, most recently from fd05ea1 to 7051a6b Compare October 16, 2026 22:34
@michaelchadwick
michaelchadwick marked this pull request as ready for review October 16, 2026 22:45
@michaelchadwick
michaelchadwick marked this pull request as draft October 16, 2026 22:59
@michaelchadwick
michaelchadwick force-pushed the frontend-6927-school-vocab-manager-overhaul branch from 7051a6b to dab366b Compare October 16, 2026 23:27
@michaelchadwick
michaelchadwick marked this pull request as ready for review October 17, 2026 16:54

This branch has not been deployed

No deployments
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.

[meta] overhaul school vocabulary term management interface

3 participants