Let everyone change due dates and self-assign and self-unassign #157
Labels
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Grandiras/Ponente#157
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
🤖 On it — follow along in the action run; the reply will link the full session transcript.
📜 Live transcript — updating every ~5 minutes while the task runs.
Pushed to
claude/issue-157.What changed
A card stays its author's (or an admin's) to rewrite — but two things on it were never really about what the card says, and locking them behind authorship made the board worse:
Everything else on somebody else's card — title, description, tags, Delete, "move to another board" — is unchanged.
How
CardPermissionsgrows two rules:CanSetDueDate, which takes no card because the answer does not depend on one, andCanSetAssignees— the one rule in the file that judges a difference rather than a row. Whoever may edit the card may write any list; everybody else may write the one list whose symmetric difference from the stored one is their own DID and nothing else.CardService.SetDueDateAsyncis a separate method rather than a lenientUpdateCardAsync, so the write that is allowed physically cannot carry a title with it and does not have to be trusted not to.MemberService.SetCardAssigneesAsyncnow reads the current rows before it checks — the opposite order to every other guard there, because the question needs both lists to be answerable.The dialog on somebody else's card is therefore no longer read-only, so
CardModal's footer Save is unconditional and Cancel no longer becomes Close. The assignee picker in that state narrows to the people already on the card plus the reader's own chip (AssigneePicker.OnlyDid) rather than showing the whole allowlist greyed out. BothBoardPage.SaveCardandCalendar.SaveCardsplit the save by what each rule governs rather than by diffing what came back.Also in the branch: a
Changelog.Unreleasedline in both locales, and the paragraphs this outdated indocs/boards-and-permissions.md,docs/calendar.mdanddocs/ui.md.Verified
dotnet build Ponente.slnclean;dotnet test395 passed, including six newCardPermissionscases covering every direction the assignee difference can point (on, off, somebody else's name either way, an unchanged list,BoardViewer.None).tests/e2e/permissions.spec.js— extended to drive the second member through setting a date and putting themselves on and then off the admin's card, reading both back after a reopen, and confirming the title is still not theirs — passes against the compose stack (built and run here via the dind host).One caveat, reported plainly: a full
npx playwright testin this job container came back 122 passed / 20 failed. Those failures are the prerender racedocs/testing.mdalready documents for CI ("a click issued on a page whose circuit has not attached yet"), not this change — I checked rather than assumed. Runningcalendar.spec.jsalone gave 14/11 with the change and 10 failures on a clean, stashed tree with the image rebuilt, with an overlapping failure set; the due-date test atcalendar.spec.js:121fails identically on both, and its DOM dump shows the card created with its date on the board and simply no dialog opened by the un-retried click.permissions.spec.jspassed in the full run and standalone.⏱ 38m 11s · 527 turns · tokens: 264.5k in / 98.0k out (+108486.2k cache-read)
📜 Full session transcript
→ Opened PR: #158