Allow customization of where $merge creates the temp collection used when rehydrating data from Online Archive --> Atlas
When you restore data from the Online Archive back into your Atlas cluster (aka "rehydrate") you need to use $merge within an aggregation pipeline. What isn't documented is that $merge will create a temporary collection in the same database you're rehydrating to, which requires that you have readWrite@<dbName> privileges so that the new collection can be created.
For customers that operate on the "principle of least privilege," where you only grant literally exactly what is needed to accomplish database CRUD operations, the user would the more narrowly scoped "readWrite@<dbName>.<collName>" privilege granted to the user to scope the actions to only the collection itself, thus not opening up readWrite capabilities for other collections in the same DB. For those customers, the $merge will fail with an error like:
MongoServerError: failed to execute $merge into <DB>.<COLL>: not authorized on <DB> to execute command { aggregate: "tmp.agg_merge.d8af7e12-3f40-4b9c-b0b8-a9aef271a89f", allowDiskUse: false, comment: "via Atlas Data Federation, correlationID = xxxxxxxx", pipeline: [ { $merge: ...
Since those narrow privileges won't permit the creation of the "tmp.agg_merge.<UUID>" collection within the DB they're rehydrating data to. Adding an option to the $merge aggregation stage that would allow the customer to control which DB the temp collection is created in, or to explicitly specify fully namespace of the temp collection (so that they can pre-grant the privileges needed for the user within Atlas) would allow customers to not have to violate internal security policies in alignment with the "least privilege needed" paradigm.