Private/restricted Projects (visibility scoped to selected members, not the whole Circle)

[raulanatol]

Feature Request: Private/restricted Projects (visibility scoped to selected members, not the whole Circle)

Problem

Right now, visibility in Donetick has two levels:

• Circle-level: everything in a circle is visible to every member.
• Chore-level: IsPrivate on a chore restricts visibility to the creator + assignees (Chore.CanView).

There's no equivalent for Projects. GetCircleProjects returns every project scoped to a circle_id, with no per-user filtering:

func (r *ProjectRepository) GetCircleProjects(ctx context.Context, circleID int) ([]*pModel.Project, error) {
    var projects []*pModel.Project
    if err := r.db.WithContext(ctx).Where("circle_id = ?", circleID).Order("name ASC").Find(&projects).Error; err != nil {
        return nil, err
    }
    return projects, nil
}

This means any project — including one a user creates for themselves (e.g. a "Personal" project) — is visible to every other member of the circle. For households sharing a single circle (the common self-hosted use case), there's no way to keep a personal set of tasks organized under a project without every task also being manually marked isPrivate.

Proposed solution

Add the same visibility pattern that already exists for chores, one level up, at the project level:

1. New field on Project: IsPrivate bool (default false, so existing projects stay visible — no behavior change on upgrade).
2. New table project_members: project_id, user_id — the list of users allowed to see a private project, beyond its creator.
3. Project.CanView(userID, circleUsers): mirrors Chore.CanView — if not private, anyone in the circle can see it; if private, only the creator and listed members can.
4. Chores inherit the restriction: a chore's visibility becomes chore.CanView(...) && (chore.Project == nil || chore.Project.CanView(...)). A chore's own isPrivate flag and its project's privacy would both apply (whichever is stricter wins), so existing per-task privacy keeps working unchanged for chores with no project.
5. Migration: backfill is_private = false for all existing projects, same approach as 20250825_set_existing_chores_private.go did for chores (but defaulting to public, to preserve current behavior).

Frontend

The "Privacy Settings" UI already built for chores in ChoreEdit.jsx (Public / Limited radio + assignee picker) is a close match for what a project's privacy control would need — same interaction pattern, different membership list (project members instead of chore assignees).

Why this is a small change

The mechanism isn't new — it's an extension of the exact pattern Chore.IsPrivate + Chore.CanView already implements and enforces at the SQL layer:

(chores.is_private = false) OR (chores.is_private = true AND (chores.created_by = ? OR chore_assignees.user_id = ?))

The same shape of query would apply to GetCircleProjects, plus a join-through when listing chores so a chore under a private project respects that project's membership.

Backward compatibility

• Default is_private = false on the new column means zero behavior change for existing installs until someone opts in.
• No changes needed to DT_SINGLE_CIRCLE_INSTANCE or existing circle-level permission logic.

Related discussions

This overlaps with the underlying problem raised in #594 "Managing multiple circles" and #448 "Multi-Circle Support" — both describe wanting to keep personal tasks separate from a shared household circle. Those threads lean toward solving it via multi-circle support (switching/viewing multiple circles per account), which is a bigger architectural change.

Project-level privacy wouldn't replace that — multi-circle support is still valuable for people who want fully separate spaces (different labels, different members, different notification channels). But it would cover a good chunk of the same need with much less surface area, reusing the exact mechanism Chore.IsPrivate already implements, for people who are fine sharing one circle but want to organize personal tasks under their own project without the rest of the household seeing them.

Open questions for maintainers

• Should project privacy and chore privacy be independent, or should a private project force all its chores private regardless of their own flag (simpler mental model, but less flexible)?
• Should circle admin/manager roles bypass project-level restrictions (similar to how they can complete any public chore today), or should private projects be strictly opaque even to admins?
• Naming: project_members vs. reusing a more generic ACL table if something similar is planned elsewhere.

Happy to put together a PR for this if the approach sounds reasonable — wanted to check the design direction first per the contribution guidelines before writing code.

[meauxt]

Hi @raulanatol, that sounds good. Let me get back to you in the next couple of days about the open questions. Thank you for putting this together!

[meauxt]

Hi @raulanatol!

• If we have a private flag on a project, then all tasks within this project are private, and we should disable the toggle on the task creation page and show this getting inherited by the project or something. And once the flag changes on the project itself, we need to make sure to update the tasks accordingly
• I think private projects staying private. Today, if a task is private, it's also private from the admin
• Sounds good!

[meauxt]

I think keeping the control at the task might even remove the need to update the query and make the read path simpler

[raulanatol]

The PRs for this are up:

• Backend: Add private projects visible only to their creator #749 — is_private on projects, chores inheriting it, propagation on flag change (with a sync_version bump so delta-sync clients see it), and tests.
• Frontend: Add privacy control to projects and inherit it on tasks frontend#169 — privacy checkbox on the project form, inherited-and-disabled privacy control on tasks, Private chip in the project list. Needs the backend one to land first.

I followed your answers: a private project forces all its tasks private and the task toggle is disabled with an "inherited from the project" hint, private stays private for admins too, and the flag propagates in both directions when it changes on the project.

I left project_members out. With tasks inheriting privacy, a member who isn't an assignee still wouldn't see the tasks, so it would need the chore read path to change too — which is what you wanted to avoid. It can be added on top later without a breaking change.

One thing I ran into while doing it: chores assigned to "Anyone" fan their reminders out to every circle member without checking visibility, so a private "Anyone" chore was sending its name to the whole circle. It was already reachable through the API, but private projects make it easy to hit from the UI, so I fixed it in the same PR.

I also spotted two pre-existing gaps that affect private chores today and left them alone — no tombstone when a chore becomes private (stale copies on clients that already synced it), and BroadcastToCircle sending chore events to the whole circle with no visibility check. Both are noted at the bottom of #749; happy to take either as a follow-up if you want them.

[meauxt]

Thank you will take a look this weekend! Appreciate the contribution @raulanatol !

[mcassaniti]

Thanks heaps. There's a bit missing though for the self-hosted use case and you are not the only project to miss it.

Think of a family using this for managing tasks with their children, especially when trying to reward their children for their hard efforts which this project supports so well. You'd ideally want:

• Adults to manage all the task settings (frequency, points, etc)
• Children to view, add comments and mark done

Now I'll admit I haven't read the code hard, but the above suggests you would want a "can update" option. If "can view" already means that a user can mark a task done and add comments then I'm sorry to have wasted time mentioning something that is already implemented.

I really like donetick and I'm trialling it with a couple of other similar projects. It means I've sometimes forgotten what one project can and cannot do currently. Like I said though, other projects have missed "can update" as well.