Feature Request: Role-based filtering and shared tables

[matthieup240]

Hi,

First of all, thank you very much for this fantastic project!
I have a feature request that I believe could improve the library's utility for more complex applications.

My needs are:

• Disable user_id filtering: Is it possible to have an option to not filter queries by user_id for certain tables? In a collaborative application, it's common to have tables that aren't owned by a specific user but are shared by everyone.
• Filter by user role: I would also like to manage data visibility based on a user's role (e.g., an admin can see all data, while a standard user only sees their own). This would simplify permission management at the database level.

I would be very grateful if you could consider these improvements for future versions of the library.

Thank you again for your excellent work.

[Mr-Pepe]

Thanks for opening this issue!

1. Sounds reasonable to me, but I don't know if and when I'll find the time to work on this. PR (+ tests) welcome.
2. Can you tell me more about your use case? I think that permission management should absolutely live at the database level. Doing the filtering at the application level seems like a bad idea because that means your database exposes everything to everyone.

[matthieup240]

Thank you for your reply and your openness to my suggestions.

I have just created a new Pull Request titled "Add sync event notifications for UI updates" as a first step. This PR is an independent feature that I believe will greatly benefit the library by providing immediate feedback on sync progress to the user interface.

Regarding my initial request on role-based filtering, here is a more detailed use case to clarify my approach:

In a multi-user application with an admin role, a manager should be able to connect and access the entire database, not just the items linked to their own user_id. A standard user, however, should still only be able to see their own items.

My approach relies on Supabase's Row Level Security (RLS) to handle the filtering and access control. RLS policies would be configured as follows:

Standard user: auth.uid() = user_id

Admin user: true (or a condition checking for an admin flag in a user profile table)

The issue with the current syncable implementation is that it always adds a client-side filter (.eq('user_id', auth.uid())) to the Supabase query. This prevents an admin from requesting a full dataset, even if the RLS policy is set to allow it.

My proposal is to modify syncable to conditionally omit this client-side filter. The library would check if the connected user is an admin (e.g., via a callback or configuration) and, if so, send a query without the user_id filter. The Supabase RLS would then correctly serve the full dataset, maintaining security.

This approach ensures that permission logic remains server-side while allowing syncable to be a more flexible tool for different user roles.

I hope this clarifies my perspective. I am happy to discuss this further and work on a new PR for this feature as well.

[Mr-Pepe]

I think your request makes sense. You want to basically always sync everything that the user has access, which would be determined by the RLS policies in the backend, right?

But what if you have multiple users on the same device? A user should (and probably wants to) only see their own data from the local Drift database, so filtering by user ID is required locally. But I guess that's not a concern in your application?

At what level would you like to have control over this? Would a global flag on the SyncManager work? Or would you want to control it for each SyncableTable?