Complex Authorization

At the moment we implement a SaaS like app for a customer which has a complex authorization system. It is complex, cause the are three kinds of users: admins, parents, and children (the last two are an example). However, while it would be okay to have all parents and children in one group each, they also need to be in their own respective group. These groups need to have a relationship to each other. For example we have Mr. and Mrs. Smith which are both members of the "Smith Parents" group, and we also have Elisa and John, which are both members of the "Smith Children" group. Now the children should know who their parents are and the other way around. Also the parents should be able to set right for their children. Imagine on a collection like toys. Also the parents need to be able to see and control everything the children do, so do the admins with everybody. Etc.

At the moment we realised this behaviour by creating collections like parents, which (next to its document ID) has only one field: team_id, which is the ID of, lets say, the "Smith Parents" group. This way we can be sure that all parent groups can be found in that collection. This generally works, however, it causes the problem that, from this point onwards, we need to do all queries via Could Functions. Which creates quite the overhead and does not feel very Appwrity.

Is there a better, recommended way to achieve this?

Hi! we do provide functionalities that can help streamline this, though you might still require some custom logic to make everything fit well.

1. Use Teams:
   • Appwrite has a Teams API https://appwrite.io/docs/client/teams that allows you to group users. You can use this to create a team for each family
   • Within this team, you can assign roles like "Parent" and "Child" to differentiate between the users. This will let you segment permissions based on these roles.
2. Utilize Permissions:
   • When a child or parent creates a document (e.g., a toy), the read and write permissions can be set to the team ID of that family. This means that all members of this team can read and/or modify this document.
   • For specific permissions, you can set the read and/or write permission of a document to a specific user ID. This can allow parents to restrict certain toys to specific children. https://appwrite.io/docs/permissions
3. Relationships:
   • If you are using 1.3 or later versions, you can use Relationships attribute.
   • Create a 'families' collection where each document represents a family, containing fields for parent IDs and child IDs. This provides a clear relationship mapping.

If you are using 1.3 or later versions, you can use Relationships attribute. That is true and a very nice and useful feature. Sadly it is not available in Cloud. 😦

We are working on updating cloud to latest version, once done it will be available

When will this be ready to use? Looking forward for it!

It’s hard to tell an approx date but we are working on releasing 1.4 for self hosted first pretty soon and then migrate cloud to 1.4

Thank you. This is all very informative. However, it causes a new question for us.

When a toy is created, we need to set the permissions in the toy. However, if the child (in front end) can set the permission itself, it can cause havoc. So we do not want to do this for reasons of stability and security. So we want to do it in a (cloud/ server side) function. Those have hooks for several events like on creation of a new toy (Document). This however causes the question if there is a time where the new toy already exists as a Document, but has not the completely correct set rights, which could cause problems (irritation of users for seemingly invisible data, small time windows with security issues, etc.).