- How would you handle searchable content where the content to search is “user centric” and his access is determined by hierarchically arbitrary nested business logic (like Files/Folders relation tree system with permissions) ?
- Is there any other way than creating on each record a “visible_by” list with all users who can access a content for private records ?
- Is Algolia a good use-case for this or are we trying to fit square box into circle holes ?
I took a look around the documentation and use-cases of Algolia (BTW the on-boarding experience is really good on both docs and website itself). But I still have some doubt about if it’s the right solution for us.
I would love to have some ROE/advises if someone already experienced implementing Algolia in the same kind of product that we develop.
Our product is an SAAS which allows companies to collaborate on projects. Basically, it’s really close to Github in term of functionalities.
- Company can create repo, invite members in it, and manage their access.
- Members of a company can create projects within it and invite members on it (from the same company or another one) and manage their access to the project.
- Each Project has content (files/folders structure, tasks, …) with once more, a way to handle permissions (eg: a folder in the project can be only accessible to the project admins, …).
To handle that, we have the relational database and business logic for the permissions to access/display data.
In term of usage, we would like for the user to have a “global search” which will always expose “all the content he could access to” and a way to prioritize the results order depending on the context he’s using the search on client side (eg: if he’s on a project list and search for “Document 1”, first search if a project is named that way, then search in other sections like “files” if we find a result).
What I’m wondering about, is that our product does not contain “public global data” as I found in most of the use-cases of Algolia.
The data we want to search in are all submitted to a lot of permissions constraint (eg: as a user, I can be in a company repo, but not have access to project X or file Y).
Our main concerns are how we should approach both, indices and data structuring for Algolia. And also, how to keep them in sync with our permission system without too much load.
Mainly because permissions on an element can impact in cascade a lot of other elements, example for Files/Folders access inside a project:
- If someone change my access permission on the project I could gain / loose access to a file.
- If someone change my group in the project, I could gain / loose access to a file.
- If someone change the permissions on the file itself, I could gain / loose access to a fail.
I don’t see any really viable solution to handle that without really quickly hitting the limits of either the indexing or operations numbers. This for instance: User-Restricted Access to Data | How to | Security | Guide | Algolia Documentation
Is a “good way” to handle the permissions. But it means possible thousands of updates if someone is added/removed from a group on top of the hierarchy (eg: someone is added to the project. I must update all the related entities on Algolia side (tasks, files, …) to add this new person to the “visible_by” array).
I’m open to documentation, articles or any insight on similar topic.