Skip to Main Content

MongoByte MongoDB Logo

Welcome to the new MongoDB Feedback Portal!

{Improvement: "Your idea"}
We’ve upgraded our system to better capture and act on your feedback.
Your feedback is meaningful and helps us build better products.

Status Submitted
Created by Guest
Created on May 25, 2022

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.
  • Guest
    Oct 18, 2023
    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.
  • Guest
    Aug 4, 2022
    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.