#community-help

Implementing Visibility Rules in Search Engine

TLDR Dima shared a problem with visibility rules for documents in a dataset. Jason recommended using Role Based Access Control, filters, and "OR" (introduced in version 0.24.0).

Powered by Struct AI
+11
raised_hands1
smile1
sweat_smile1
17
6mo
Solved
Join the chat
Mar 13, 2023 (6 months ago)
Dima
Photo of md5-1b62114a658b760944aa7d2b4c274460
Dima
08:52 PM
Hi team! Maybe you know a better way to solve this problem 🙌 Details in the thread.
08:54
Dima
08:54 PM
I have dataset of documents and also hierarchy or users. For simplicity of reproducible example each user belongs to a team, and each team belongs to a department.

Some of documents in my dataset have different visibility rules and I want to reproduce them in the search engine. For example:
• Article with list of employees, available for the whole company
• Article with internal department rules, available for department1 (i.e. for all teams in this department)
• Article with internal team’s drafts, available for team1
My first idea was to use arrays for such visibility fields and then fullfill them with corresponding values. If visibility chosen as department1 , we will add corresponding teams too. Solution looks like this

Problems with this solution are:
• Some people can be outside teams or departments. For example CEO or other leaders.
• We need to update index every time when new teams are created, otherwise they will get empty results (e.g. newcomer team5 won’t get even publicly available documents)
Jason
Photo of md5-8813087cccc512313602b6d9f9ece19f
Jason
08:57 PM
Your examples sound very close to what is described here under Role Based Access Control: https://typesense.org/docs/0.24.0/api/api-keys.html#role-based-access
08:58
Jason
08:58 PM
> Some people can be outside teams or departments. For example CEO or other leaders.
You could add them to an internal admin “system” team of sorts, that is not exposed to your end users
08:59
Jason
08:59 PM
> We need to update index every time when new teams are created, otherwise they will get empty results (e.g. newcomer team5 won’t get even publicly available documents)
You could create another attribute called is_public: true|false in each document
Dima
Photo of md5-1b62114a658b760944aa7d2b4c274460
Dima
08:59 PM
And then run two searches and merge them back?
Jason
Photo of md5-8813087cccc512313602b6d9f9ece19f
Jason
08:59 PM
and then your filter can be:

(departments:=[`department1`] && teams:=[`team1`]) || is_public:true
Dima
Photo of md5-1b62114a658b760944aa7d2b4c274460
Dima
08:59 PM
Do you support OR? 🌚
Jason
Photo of md5-8813087cccc512313602b6d9f9ece19f
Jason
09:00 PM
In the latest version 0.24.0 yes!
Dima
Photo of md5-1b62114a658b760944aa7d2b4c274460
Dima
09:01 PM
Jason
Photo of md5-8813087cccc512313602b6d9f9ece19f
Jason
09:01 PM
Yeah that would work too
Dima
Photo of md5-1b62114a658b760944aa7d2b4c274460
Dima
09:02 PM
Ah, it looks I have a logic error in my example, I will check it and return later. Thank you!
+11
09:05
Dima
09:05 PM
Could you please check the latest gist?

I got only "available for all" document, but expected "available for department1 (so for all nested teams)" too, because departments contains department1 🤔
Jason
Photo of md5-8813087cccc512313602b6d9f9ece19f
Jason
09:07 PM
Could you confirm you’re using v0.24.?
Dima
Photo of md5-1b62114a658b760944aa7d2b4c274460
Dima
09:08 PM
0.24.0.rcn56. Let me update it to the latest one
09:10
Dima
09:10 PM
Sorry, my bad. Had outdated docker build
sweat_smile1
09:10
Dima
09:10 PM
Now it’s working as it should be! Thank you for the OR, it’s lifesaving
raised_hands1
smile1