Closed doceazedo closed 2 months ago
The provided example, especially the back-relation, seems out of place for me.
I'm also not sure that I understand how exactly it helps mentioning "useful for apps that serves multiple tenants, organizations or teams" because in the shown examples the alias has no effect (or at least it is not clear why users should use it if there is no other @collection.*
rule with the same collection).
In any case I will keep the above in mind when writing the new docs for v0.23 as part of the ongoing refactoring but for now I'm not going to merge the suggestions.
Having organizations/teams/tenants is a quite common scenario, and PocketBase docs is a bit lacking in that regard, despite supporting those cases very well, so here are some changes:
I couldn't find anything related to the
:alias
modifier apart from the brief mentioning that links to https://github.com/pocketbase/pocketbase/discussions/3805. That itself is very confusing because of the usage of:auth
without disclaiming it's an arbitrary name. So I clarified that and added a dedicated section for it in the \"API rules and filters\" page based on https://github.com/pocketbase/pocketbase/discussions/4097.Back-relations are super useful in itself, and as mentioned on the discussion, you might not even need aliases if you use back-relations. Even so only aliases are mentioned in this page... so I added some references to back-relations, the first one coming before the
:alias
topic to avoid confusion.I also added two new examples that can be useful for these use cases. One for checking if the user is a member of an org/team using back-relations, and the other for checking if a value is already in use by other collection (that can also be useful for having unique usernames between the
users
andorganizations
collections).