Auth and Group Permissions skill#4
Conversation
| at the user resource. Both keys must exist on the join — the action looks | ||
| them up by name when the membership row is saved. | ||
|
|
||
| The join also needs a Save Submission action (priority 10) — Save and Group |
There was a problem hiding this comment.
I wonder if this should be removed since forms/resources have save submission action added automatically. I was getting duplicate save submission actions on the join resource and the test form utilizing group permissions when I prompted claude to scaffold out group permissions (it used this skill).
travist
left a comment
There was a problem hiding this comment.
Many changes needed. Please review.
| project — new or existing. Use when the user wants to add login or | ||
| registration to an app, assign roles on signup, restrict records to a | ||
| user's team / project / company / tenant, debug "I can see the parent but | ||
| not its children" group-permission bugs, set up the four-empty-roles |
There was a problem hiding this comment.
This line seems strangely specific. "I can see the parent but not its children" group-permission bugs. I am not sure what that means.
| field-based access block, or wire up transitive group access for resources | ||
| two-or-more levels below the group. Also use when the user mentions | ||
| Group Permissions, Group Assignment, group-based access, role-based access, | ||
| owner-based access, the `user` resource, login resources array, hidden |
There was a problem hiding this comment.
Not sure the user will mention login resources array or hidden calculated mirror selects. I don't know what that means.
| two-or-more levels below the group. Also use when the user mentions | ||
| Group Permissions, Group Assignment, group-based access, role-based access, | ||
| owner-based access, the `user` resource, login resources array, hidden | ||
| calculated mirror selects, or `data.<parent>.data.<group>` calculateValue |
There was a problem hiding this comment.
I don't believe this skill should be used for any 'calculateValue' expressions. I worry that an agent would read this and pick this skill if the user asks about calculated values.
| 1. **Custom authentication** — a user resource, a login form, a register form, | ||
| and a role-assignment action that together let real users sign up, sign in, | ||
| and carry a role. | ||
| 2. **Group-level permissions** — a join resource, a Group Assignment action, a |
There was a problem hiding this comment.
a join resource is only used for many-to-many group permissions. one-to-many do not require this, and instead simply use a resource select dropdown within the child resource pointing to the parent resource.
|
|
||
| - "Add login to my app" / "let people sign up" / "wire up registration" | ||
| - "Restrict records to the user's team" / "users only see their company's data" | ||
| - "Group permissions aren't propagating to child records" |
There was a problem hiding this comment.
I would like to come up with better 'prompts' that the user may actually say. "Group permissions aren't propagating to child records" does not seem to be like something someone would say. Instead, it may be something like this...
"If I belong to a group, I should only be able to see data and information within that group".
| 1. **Save Submission** (priority 11) — writes the submitted fields into the | ||
| `user` resource via the action's `settings.resource` + `settings.fields` map. | ||
| 2. **Role Assignment** (priority 1, after-handler) — attaches the | ||
| `authenticated` role to the new user. |
|
|
||
| - A **group resource** (e.g., `Project`, `Team`, `Company`) — submissions are | ||
| the groups themselves. | ||
| - A **join resource** (e.g., `ProjectUser`, `TeamUser`, `CompanyUser`) — |
There was a problem hiding this comment.
join resource is only necessary for many-to-many relationships. We need to have docs over how to create one-to-many relationships.
| the groups themselves. | ||
| - A **join resource** (e.g., `ProjectUser`, `TeamUser`, `CompanyUser`) — | ||
| M:N between users and groups; each row is a membership. | ||
| - The **Group Assignment action** on the join — when a membership is created, |
There was a problem hiding this comment.
"on the join"... this should be specific. 'added to the join resource for many-to-many relationships, and on the group resource for one-to-many relationships'
| at the user resource. Both keys must exist on the join — the action looks | ||
| them up by name when the membership row is saved. | ||
|
|
||
| The join also needs a Save Submission action (priority 10) — Save and Group |
| "input": true, | ||
| "tableView": true, | ||
|
|
||
| "submissionAccess": [ |
There was a problem hiding this comment.
I would like to investigate why this is needed.
Pulled out the auth and group permission instructions that were in the resource planning skill so they can be activated outside of that workflow