You mean the teams feature?
Database relationships and Auth Teams
Votes
0
Replies
24
Participants
Unknown
Messages
25
I think that the best way is using the teams feature to manage permissions and the database for everything else
Rank 1: Thread
But my permissions are "you can only read and write stuff associated with your team"
Rank 1: Thread
Which I don't think is odd per-se, right?
Rank 1: Thread
Or am I placing semantics on Team which don't apply to it?
Rank 1: Thread
I'd still need a way to associate identity to a resource though, like which users are in the codename "Organization", which is a collection I have in my database
Rank 1: Thread
Ok I've take a look at what Teams can do, I am abusing its semantics.
So the question is now, how do I associate Users to documents?
Teams allow you to group permissions so you give them to the entire team instead of a particular or some specific users.
When you create, you set an array with the permissions:
https://appwrite.io/docs/advanced/platform/permissions
Rank 1: Thread
Forget permissions for now, lets say there are no premissions in my application
Rank 1: Thread
it's unrelated to my question in actuality
Well, if there are no permissions, no one will be able to access the docs.
Unless you grant permissions for everyone
Rank 1: Thread
then permissions are fully lax, everyone can do anything including guests
Rank 1: Thread
like I said, it's a totally unrelated conversation
Okay, so I think I didn't understand it well 😅
Rank 1: Thread
I want the moral equivalent of doing GET /things?organization=123, and more importantly I want the moral equivalent of GET /organizations?userId=123
Rank 1: Thread
not literal equivalent, I'll be using the SDK, I need to have some sort of abstraction that allows me to group users into organizations
So basically you mean grouping documents?
Rank 1: Thread
yes
I think best way could be having a collection with all the organisations and then in the grouped docs setting a foreign key (a string) with the document ID that contains the org ID
An alternative are relationships, but you will not be able to query properly, so that's why I suggest using foreign keys for now
Rank 1: Thread
in a not-appwrite app I'd have Organization, Member and User. Organization has many Members and a User can have many Memberships. But in this case I can't associate the User with a Membership
Rank 1: Thread
so just using a String attribute and wingging it?
Rank 1: Thread
could you elaborate on this? Relationships are not the blessed way to represent relationships?