Hi everyone!
I have a screen in my app that displays a table with many filters and search options. This table should look slightly different depending on the user's role. For example, Admins should see more columns and have access to additional filters.
I'm considering a few different approaches and I'm not sure which one is best:
1. Create two different blocks and display them based on the role. This means maintaining two views, which could lead to duplicated code and more maintenance.
2. Use one aggregate, one view and control the visibility of columns, filters, etc. based on user role. This reduces duplication but increases the risk of bugs and potential data leakage through the API.
Does anyone have experience with this or suggestions for a better approach?
Hello @Łukasz Kaproń,
I’d suggest going with one block and controlling the visibility of columns/filters based on the user’s role. This way, you avoid code duplication, and it’s easier to maintain.
The key point is to make sure role restrictions are also applied on the data source (aggregate or server action) and not just by hiding UI elements, otherwise sensitive data could still leak. Use the Visible property or If conditions to hide/show parts of the UI depending on the role.
If the difference between roles is really big (almost two different screens if we talk about widgets), then it might be cleaner to create two separate blocks
Thanks
Regards
Gourav Shrivastava
Hi @Łukasz Kaproń ,
Instead of using an aggregate, you can use a data action with the aggregate or SQL node to control the output based on the role. This way, you won’t need separate blocks.
You can then verify the output in DevTools under the Network tab so there is no leakage.
It might be a good solution, but I also need pagination. From what I can see, it doesn't seem possible to implement pagination in an Aggregate within a ServerAction - or I just don't know how to do it?
Is not supported out of the box, but you can do it by following this guide: Paginating, sorting and filtering data from a Data Action .
I think you should go with One block with role-based visibility is better
Use a single aggregate and a single block. Control which columns and filters are visible with If conditions or role checks. This keeps logic centralized and avoids duplication.
To prevent data leakage:
Limit the query itself to only fetch data the user’s role is allowed to see. Don’t just hide columns on the UI — enforce restrictions in the aggregate/SQL.
For pagination, you can do easily with aggregate