Repository navigation
fix(desktop): show owning-profile badge on cron job rows - #96554
Closed
SmelterLabs wants to merge 1 commit into
Closed
SmelterLabs wants to merge 1 commit into
SmelterLabs wants to merge 1 commit into
Conversation
The backend stamps every cron job with its owning profile (web_server _annotate_cron_job), but the desktop UI dropped the field so cross-profile (aggregated) cron lists gave no clue who owns a job. Reuse the existing ProfileTag chip (already worn by session rows) on cron rows in both the sidebar section and the full cron page. No backend or API changes.
Author
|
Closing this stale PR to keep the queue tidy. Happy to rebase and reopen if there is interest. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
The backend already stamps every cron job with its owning profile
(
web_server.py→_annotate_cron_jobaddsprofile,profile_name,hermes_home,is_default_profileto each job in the/api/cron/jobsresponse, for both the aggregatedprofile=allfetchand single-profile fetches). The desktop UI dropped the field: the
CronJobtype never declared it, and neither the sidebar cron sectionnor the full cron page rendered it.
In an aggregated (all-profiles) cron list, every job looked identical —
no way to tell which profile owns and fires it. This adds a small
owning-profile chip to each cron row, reusing the existing
ProfileTagcomponent that session rows already wear, so the badge is visually
identical to the profile chips in the session list.
No backend or API changes — pure display.
Related Issue
No issue filed. Follow-on display gap from the profile-identity work
(see #94450, which this does not depend on — it only consumes data the
backend already ships).
Type of Change
Changes Made
apps/desktop/src/types/hermes.ts— addedprofile?: null | stringto the
CronJobinterface (field already present in API payloads).apps/desktop/src/app/chat/sidebar/cron-jobs-section.tsx—CronJobSidebarRowrenders<ProfileTag profile={job.profile} />after the job label when the field is present.
apps/desktop/src/app/cron/index.tsx—CronJobListRowpasses thesame chip through
PanelListRow'smetaslot.How to Test
cd apps/desktop && npm run build && npx tsc --build tsconfig.json— typecheck clean.
npx vitest run src/app/cron src/app/chat/profile-tag.test.tsx src/app/chat/sidebar/cron-jobs-section.test.tsx— all pass(35/35 on this branch).
sidebar in the aggregated (all-profiles) view — each row now shows
its owner's chip. Same for the full cron page (Cmd/Ctrl-shift-C or
the cron icon). Single-profile view is unaffected visually (chip
shows the one owner, consistent with session rows).
Checklist
Code
fix(scope):,feat(scope):, etc.)tsc --build,eslint, andvitest run src/app/cron src/app/chat/profile-tag.test.tsx src/app/chat/sidebar/cron-jobs-section.test.tsx— all pass (35/35). Pythontests/untouched by this PR (display-only frontend change).ProfileTagcomponent and the touched rows are covered by the existingcron-jobs-section/cronsuites.