Allow to pass user on Realm's Database Triggers
Currently I can create a Database Trigger, that when calling its Function I can restrict based on "%%user" - through "Can Evaluate". Though since the Function is called by a Trigger and therefore runs as a "system user" I cannot access the User object (or its details) within the Function - I (personally) mainly want the userID & email - though whole object would be better.
Since a Function is called by a Trigger and therefore it runs as "System User" - Please allows us to pass an array of arguments for the Function. This could be a field after selecting the Function in the setup for a Trigger. We then would have to setup matching parameters for such Function.
Reveel®
shared this idea
-
Richard
commented
I wholeheartedly agree with you and @Guillaume. The lack of access to the User object and Request details in Database Triggers isn't just a technical limitation—it's a business one. This feature is fundamental for implementing robust server-side logic which are essential for auditing, permissions, and complex workflows. But more than that, it's a monetization opportunity. Imagine the new use-cases and services companies could offer with this kind of flexibility. As someone deeply involved in backend and game development, I can attest that being able to fine-tune our logic without resorting to cloud functions and AWS deployments—especially when we're on GCP—could be a significant cost-saver and an incentive for wider adoption of Atlas services. Adding a parameter field when setting up a Trigger to pass this information would make Atlas not just a more powerful tool, but also a more financially attractive one.
-
Guillaume MOREL-BAILLY
commented
Hello,
It's also important for us. But instead of passing the user as a parameter, it would be better I guess to have access to the current signed-in user that has executed the request linked to the trigger. We need that to automatically update properties like `createdBy` and `updatedBy`.
Currently, we use parameter on the frontend side. It's not safe since the user can intercept the request and change the parameter.