[REQ] Option to exclude specific chores from the Shared OpsCenter view

[Nigatsu]

Feature area

Integration logic/state

Problem or use case

No chore can be hidden from specific profiles. Every chore is visible to everyone — sensor, dashboard, OpsCenter, calendar. That's fine for shared tasks, but breaks for things one household member manages about another member who's also a ChoreOps user:

• Gift prep — "Wrap Sarah's birthday present" shouldn't show on Sarah's dashboard or calendar.
• Surprise parties — prep chores need to stay invisible to the honoree while still shared among everyone else in on it.
• Managing another member's medical schedule — trackable/notifiable is exactly what ChoreOps is good at, but it shouldn't sit on a shared wall tablet visible to the whole household.

Dashboard preferences (pref_exclude_states, etc.) don't solve this — they only hide a card from a default template. The underlying entity is still exposed via Developer Tools, custom cards, or OpsCenter, so it's not an actual access boundary.

Proposed solution

• Optional visible_to: [profile_id, ...] on chore config, default = all profiles (fully backward compatible).
• When set, the chore's entity/sensor/button is withheld from excluded profiles' dashboard context — not just filtered from a template.
• Calendar entries respect the same scope (otherwise a hidden chore still leaks through the shared calendar).
• Needs its own rule for admin/approver visibility: an admin who's also the gift recipient shouldn't see it via OpsCenter just because they're admin.
• Dashboard generation excludes scoped chores entirely for excluded profiles, rather than present-but-hidden.

Expected outcome

ChoreOps can handle genuinely private household coordination (gifts, surprises, one member's schedule) without a separate tool — currently that use case forces people out of ChoreOps entirely.

Scope caveat, to set expectations correctly: this can only ever be discretion from ChoreOps' own generated dashboards, OpsCenter, and calendar views — not real access control. Any HA admin can still see the underlying entity via Developer Tools → States regardless of this setting, since HA has no per-entity ACL for admins. This is worth having even with that limitation (it stops the accidental/default-view leak, which covers most real households), but it shouldn't be described as "private" in a security sense — more like "hidden from the obvious places."

Alternatives considered

Second ChoreOps instance — heavyweight, still visible to any admin.

Additional context

Yuvomi (a self-hosted family-planner app, formerly named Oikos) already uses this exact pattern — a per-item scope (family / restricted / private, default family) on its Documents module. Its Tasks module doesn't have it yet either, for what it's worth, so this isn't "copy a competitor's task feature," just a precedent for the shape of the scope field itself.

[ccpk1]

Thanks for the detailed feature request. The use cases you described could make sense for a household, so I see where you are coming from. That said, implementing a backend visible_to filter doesn't seem viable from I can think of due to how ChoreOps and Home Assistant's architecture works. Home Assistant dashboards are essentially stateless regarding who is viewing them. The backend broadcasts the exact same entity attributes to every connected user/device simultaneously. ChoreOps cannot dynamically alter an entity's data on the fly based on which family member is looking at a screen.

The current recommended approach is to use Home Assistant’s native dashboard visibility controls to restrict the OpsCenter view or an individual user chores view to only specific users.

You could also consider going a level deeper using the dashboard view visibility controls above in conjunction with the include and exclude filters so that each user would have a public chores list and a private chores list that only they could see, but I'm not sure if that would be worth the effort to you.

Let me know if you think I'm missing something.

[Nigatsu]

You're right, that entity state itself can't be filtered per-viewer, that's a real HA constraint I wasn't trying to argue around. But I don't think that's actually what visible_to would need, if I'm understanding your dashboard generator correctly. You already build per-profile generated configs — the Dashboards repo describes generating "a dedicated, individualized admin dashboard for each specific user," which is a build-time decision about what goes into person A's config vs person B's, not a runtime broadcast difference.

visible_to would just be one more input to that same generation step: when building person A's dashboard (or their individualized view), skip chores that exclude them. No entity anywhere behaves differently for two simultaneous viewers — it's the same generation-time filtering you're already doing per profile, just with one more exclusion rule.

Your view-visibility + include/exclude suggestion gets to the same result, and has the same security ceiling either way (admin can still find the raw entity via Developer Tools regardless of which approach).

The difference is just that it'd be manually maintained per dashboard rather than driven automatically off the chore config — which cuts against the "no YAML" auto-generation ChoreOps is otherwise built around.

[ccpk1]

I think I see where our disconnect is, and it possibly comes down to how ChoreOps handles things behind the scenes.

The dashboard generator doesn't hardcode individual chores into the YAML config. If it did, we’d have to regenerate the dashboard every single time a chore was added, completed, or modified. Instead, the generator builds a view that points to a specific "dashboard helper" sensor entity for that user. That sensor dynamically holds the list of chores assigned to them. (To be clear, it ONLY contains chores that have been assigned to them, so their individual dashboard view will never show chores that aren't assigned to them)

Because of that setup, two things are happening:

1. The Lovelace dashboard itself isn't aware of who is looking at it; it just displays whatever data is currently sitting inside that specific helper sensor. (The lovelace dashboard can apply visibility filters to the overall view, as mentioned, but not for the underlying data)
2. If a chore like "Wrap Sarah's Gift" is assigned to Dad, it only populates Dad's helper sensor. It won't be in Sarah's helper sensor, meaning it wouldn't show up on her personal view anyway. There shouldn't be a scenario where a chore is assigned to Sarah but needs to be hidden from her.

Because assignment already keeps tasks isolated to specific user views, I'm not entirely sure I understand what you are trying to achieve or where the chore is leaking in your setup. Or are you trying to hide it from the dropdowns inside the OpsCenter?

If you can tell me exactly which view or entity the unassigned user is seeing where they shouldn't be, it will help me understand the gap you're trying to fill!

[ccpk1]

One additional point I just thought of. Your response mentions using the per user administration view, which creates and admin view for each user, rather than the single "OpsCenter" view that allows the admin to select which user they want to perform administration for.

Are you trying to say that if a user goes into the shared administration page (OpsCenter) or their individual administration page, they can then see all available chores in the system?

[Nigatsu]

You're right about assignment isolation on personal views; I was wrong to frame it broadly. To your question: not "all chores in the system" on any personal dashboard — the leak is specific to the Shared OpsCenter, via two paths:

1. Passive — Approval Board. The admin_setup_shared snippet in dashboard_helpers.py builds helper_sensor_entities from every user's helper (user_dashboard_helpers | dictsort), and admin-shared-v1.yaml's Approval Board loops all of them, showing everyone's pending claims regardless of the Management picker (which only scopes the sections below it). So: Dad claims "Book venue for Mom's surprise party" → Mom, also an admin, opens Shared OpsCenter to approve a kid's chore → Dad's claim is sitting right there. No selection needed — that's the accidental-exposure case.

2. Active — profile picker. Selecting another profile in Management shows all their chores in Chore Management. This one's arguably by design ("you went looking"), but it's the literal answer to your question: yes, any profile's chores, one profile at a time.

The Per User admin page has neither issue — admin_setup_peruser bakes the user_id in at generation time, properly scoped.

Given how narrow this actually is, forget the broad visible_to idea. A smaller fix would cover the case that matters: an opt-out flag like exclude_from_shared_admin that keeps a chore out of the Shared view's Approval Board aggregation (and its chore picker), so it's only visible/approvable via the Per User page of whoever it's meant for. Path 2 for unflagged chores can stay as-is. Happy to retitle/narrow the issue to just this if useful.

[ccpk1]

Thanks for the thorough analysis and for narrowing the scope on this one. I appreciate the work you put into thinking through the use cases.

I'm going to leave this as a feature request for now so we can track it, but it will need quite a bit of updating for a relatively narrow use case. It will require a config flow changes, service updates, storage migration, dashboard builder updates, and approval board filtering so it will make more sense when I have a few related enhancements that require me to open all those up.

That said, there's a viable workaround today. (I think you already know this, but in case others are viewing):

• Use per-user admin pages instead of the Shared OpsCenter. These are already generated for each user and only show that user's assigned chores — so a chore assigned to Dad never appears in Mom's per-user view. You can also use the per-user admin pages with the shared admin pages and then lock them down differently.
• Restrict access via HA dashboard visibility controls on each per-user page. You can use per-user dashboard views limited to specific users, which covers the "accidental exposure" case on shared wall tablets.

This gives you most of the same practical outcome — chores stay scoped to the right people — without the backend complexity of a new visibility flag. The Shared OpsCenter showing all chores across all users is by design as the admin hub, so the workaround is really about choosing the right tool for the job.

Let me know if this is captured correctly or if I'm still missing something about the setup. Happy to keep the conversation going.