Did you ever had the challenge implementing collaboration functionality in your Amplify app?
How did you handle this?
Now, imagine we have a Document model and we have a 1:n relationship to the DocumentBlock model which represents a paragraph in the document. You want to allow collaboration or read-only access to the model. So, you have an owner field and whoever is the owner can add/remove contributers and readers (with allow.ownerDefinedIn("owner")). So, you also have an array readers (with allow.ownersDefinedIn("readers").to(["read"])) and an array contributors (with allow.ownersDefinedIn("readers").to(["read", "update"])). This works great on the document but on the blocks it gets really challenging. If you add a reader or remove one, you need to cascade that down to each of the block records (e.g., using DynamoDB Streams). And when you create new blocks you need to take all the permissions from the parent record and replicate them to the child record. This means this functionality is exposed to the frontend code. I think this is very risky and it also doesn't sound robust. Did you have this issue before? What was your solution? I am considering to build a native Amplify solution and create a PR. But, I need validation that there is a need for it. Or maybe, something in my thought process is wrong and you have a better idea 🙂
#Acknowledging permissions from parent records for child records
1 messages · Page 1 of 1 (latest)
I have added a feature request for this: https://github.com/aws-amplify/amplify-category-api/issues/3447
GitHub
Describe the feature you'd like to request In collaborative applications, authorization is defined on a parent record (e.g., a Document with owner, editors, viewers fields) and child records (e...