← All notes

A shared task list still needs separate permissions

Follow a community work center from list to detail to action: shared navigation, scoped access and the original business commands.

Basis of this note

Code reading of Shuyang Home v1.6.0, pinned to 54ac363. The scenarios below are proposed checks; the project release report is historical evidence, not a full rerun in this note.

A common entry point, different responsibilities

A member may be waiting for an activity approval, arranging a resource exchange and following an order. A shared list saves navigation, but each item still has its own owner, state and allowed actions.

The useful engineering question is what the overview is allowed to do. In this implementation it projects business records into a readable list and returns action metadata; it does not become a second order or moderation service.

Read the list and detail checks together

WorkCenter.list filters each record with permitted before producing counts and pages. WorkCenter.target runs that check again when opening a specific object. A link copied earlier therefore does not grant permanent access.

  • An organizer does not gain access to other members’ orders through the management overview.
  • A moderator remains scoped to assigned boards; a removed assignment must affect subsequent detail requests.
  • Forum moderation opens the original viewer so attachments and conversation context remain available.

What this structure buys, and what it costs

Reusing the original commands keeps their validation and transaction rules in one place. The price is maintaining mappings for each business type: labels, deadlines, action routes and state groups can drift when a source module changes.

The current list reads records by business type and filters them in the service. That is a concrete choice for this local pilot, not evidence of large-scale performance. A larger deployment would need measured query costs and a deliberate paging strategy.

Review the failure paths

  • Use member B to request member A’s item directly, not just through the list. Expect denial.
  • Load a moderator’s list, revoke the board assignment, then open its old item URL. Expect fresh authorization.
  • Remove an activity linked by a signup. The signup should explain that its target is unavailable without breaking unrelated items.
  • After a business action succeeds, refresh the list and its counts from server state. Do not infer completion from a closed dialog.

What I would carry into the next project

Before building another dashboard, I would write a small table for every item type: who can see it, who can act, which command runs, and what happens when the target disappears. It makes scope concrete before the layout gets complicated.

Sources & further reading

Compiled from code and documents, with AI-assisted drafting and translation. Examples and proposed checks are learning material; only linked evidence establishes what was run.