Feature Request: Add Parent-Only Editing Option to Tasks Module

[cruzin79-droid]

suggest adding an option within the Tasks module that allows a task to be restricted to parent-only editing.

Currently, children need access to tasks so they can select, manage, and complete their assigned responsibilities. However, it would be useful for parents to have the ability to prevent children from modifying the actual task details after the task has been created.

Proposed Feature

Add a toggle or button when creating or editing a task, such as:

🔒 Parents Only – Restrict Task Editing

When enabled, only users with a Parent role would be able to modify or delete the task itself.

Children would still be able to interact with the task as necessary without being able to change its definition.

Child Permissions

When Parent-Only Editing is enabled, children should still be able to:

Select or claim a task, if task selection is permitted.
Mark the task as Complete.
Enable or disable their Reminder for the task.
View the task details and instructions.
Perform any other normal task actions that do not modify the task's configuration.

Children should not be able to:

Edit the task name or title.
Edit the task description or instructions.
Change the task's schedule, due date, recurrence, or other configuration.
Change rewards, points, or other values associated with the task.
Delete the task.
Disable or change the Parent-Only Editing restriction.
Important Distinction

The restriction should apply to the Task definition, not the child's interaction with the task.

For example, a child should be able to:

Homework

Complete your homework before dinner.

The child could select the task, enable a reminder, and mark it complete when finished.

However, the child could not edit the task and change it to:

Homework

Do homework whenever you want.

This would allow parents to maintain control over the task's requirements while still giving children the ability to interact with and complete their responsibilities.

Suggested Behavior

When creating or editing a task, provide a setting similar to:

Restrict Editing

Parents Only

If enabled, task-editing controls could either be hidden from child accounts or displayed as disabled.

If a child attempts to modify the task through another method, the backend should also verify the user's permissions and reject the modification. This ensures the restriction is enforced by permissions rather than only through the user interface.

Potential Acceptance Criteria

Add a Parents Only / Restrict Editing option to tasks.

Only Parent accounts can enable or disable the restriction.

When enabled, only Parent accounts can edit the task definition.

Children can still view the task.

Children can still select or claim eligible tasks.

Children can still mark tasks as complete.

Children can still enable or disable their personal task reminders.

Children cannot modify the task title, description, schedule, recurrence, rewards, or other task configuration.

Children cannot delete a parent-restricted task.

Permissions are enforced on the backend/API as well as in the UI.

Existing unrestricted tasks continue to function as they currently do.

Why This Would Be Useful

This would provide a better separation between task administration and task participation.

Parents could define and manage household responsibilities while children retain the ability to interact with those tasks normally. It would also prevent accidental or intentional changes to task requirements while avoiding the need to completely restrict children's access to the Tasks module.

This could be especially useful for recurring chores, homework, household responsibilities, and tasks associated with rewards or allowances.

[ulsklyc]

Agreed on the problem, and your split between "the task definition" and "the child's interaction with it" is exactly the right line. That distinction is what the module permissions can't express today: they only know read-only for the whole module, and read-only also stops a child from ticking anything off, which defeats the purpose.

So this is going in, as a lock on the task itself. Locked means the definition - title, description, schedule, recurrence, points, and deleting it - is closed, while claiming, completing, viewing and personal reminders stay open. That is your list, and I don't think anything needs adding to it.

One deliberate difference from your proposal: the lock will not key off the family role. It will be the task's creator plus admins who can edit a locked task and lift the lock.

Two reasons. The narrow one is that "parent" isn't a single value here - the family role has seven of them, and dad, mom and parent are all parents, while grandparent may or may not be depending on the household. Any rule keying off it has to guess that list, and it will guess wrong for someone.

The broader one is that a family role says who somebody is, not what they are allowed to do. Yuvomi got this wrong once already and moved health permissions from role inference to explicit grants for exactly this reason. I'd rather not reintroduce the pattern in the Tasks module.

Creator-plus-admin covers your case without inventing a permission system: the parent who sets up the chore keeps control of it, the child can do everything except redefine it. If it later turns out that households need to hand that right to someone who is neither the creator nor an admin, an explicit grant is the honest way to add it - and it would then apply consistently rather than only to tasks.

Backend enforcement is a given, and thanks for calling it out explicitly - it matters more than it sounds, because a task is also read through the dashboard, the search and the API, and a check that only lives in the task routes would leave those open.

[ulsklyc]

Released in v2.30.0.

It went in as described: a lock on the individual task, held by the creator plus admins, not keyed off the family role. Closed is the definition - title, description, category, priority, dates, recurrence, points, visibility, tags, linked documents, filing it away, deleting it, and lifting the lock. Open to everyone stays the interaction: viewing, ticking off, commenting and personal reminders.

One line your proposal and my reply both left implicit, and it turned out to be the important one: assignment sits on both sides. Taking a task on yourself, or handing it back, is something you do with a task - that is interaction, and it stays open. Assigning it to somebody else is definition, and it is closed. Without that split the lock misses the case it exists for, because a child could simply push the chore onto a sibling without editing a single field. The check compares the assignees other than yourself before and after, so self-assignment stays free while reassignment does not.

A few other things the build settled:

• Subtasks inherit the parent's lock. A subtask is a point of the same instruction; a freely editable checklist underneath a locked task would make the lock worthless.
• The three bulk tag operations skip locked tasks instead of rejecting the whole call, and report how many were left out. Tagging forty tasks should not fail because one is locked, but a silent partial run would be worse than an error.
• The check runs in every writing route, not in one piece of middleware - you were right to call out backend enforcement explicitly. A task is also reached through the dashboard, the search, the public API and MCP, and a guard that lives in the task routes only would leave all four open.

And your insistence on backend enforcement turned up something unrelated to this feature. Going through the writing paths one by one, PATCH /:id/archive was the one that loaded the task by ID alone, without checking whether you were allowed to see it - so a guessed ID was enough to archive somebody else's private task. The same hole was closed for PUT and DELETE in v2.12.0 and this third path had been missed. It answers 404 now, because whether the task exists is itself information. That fix shipped in the same release.

[cruzin79-droid]

Thank you!
Fantastic approach to the request, creator-plus-admin.