MongoDB Permissions¶

Two separate things have to be granted before someone can put a MongoDB datastore to work, and they are granted in different places:

• On your MongoDB deployment, the database user Qualytics signs in as needs read access to the databases you monitor, and the deployment has to accept connections from Qualytics. Without it the connection cannot read your data at all.
• In Qualytics, the person doing the work needs a user role and a team permission. Without them the datastore exists but they cannot create, change, or run operations on it.

The rest of this page covers both, in that order.

Access on your MongoDB Deployment¶

Qualytics never writes to MongoDB through this connector, so read access is all it asks for.

What the database user needs¶

MongoDB's built-in read role on each database you want to monitor covers everything the connector does:

On a self-hosted deployment, grant it with a command such as db.grantRolesToUser("qualytics", [{ role: "read", db: "sales" }]), run in the user's Auth Source database. On Atlas, give the database user the Only read any database built-in role, or a custom role limited to the databases you monitor.

A server without access control needs no user at all; see Authentication.

Network access¶

Allow your Qualytics deployment to reach the MongoDB servers. The Add Datastore form shows the addresses your connections originate from, under Public addresses and Private addresses, so you can copy the ones that match your network setup into your firewall rules or, on Atlas, into the project's IP access list.

Members of a replica set can listen on different ports. Use the ports your deployment actually uses.

Hostname resolution¶

A replica set tells its clients the names of its members, and Qualytics connects to those names exactly as the replica set reports them. Every member name in the replica set configuration has to resolve from your Qualytics deployment, not only the ones you typed in Host. If a name resolves only inside your network, add the records to the DNS your deployment uses.

This is the most common reason a replica set that answers on one address cannot be read: the first member was reachable by the address you entered, and the member names it reported back were not.

Permissions in Qualytics¶

Qualytics checks two layers, and an action is allowed only when both pass.

• User roles are workspace-wide: Member, Manager, and Admin.
• Team permissions are granted per datastore through the teams a user belongs to: Reporter, Viewer, Drafter, Author, and Editor.

For the full reference, see User Roles and the Team Permissions Overview.

User Roles¶

Team Permissions¶

Checked on the datastore itself, in addition to the user role above.

How the two layers meet¶

To create a MongoDB datastore, a user needs the Manager role and the Editor team permission on at least one of the teams the new datastore is assigned to, the Public team when none is chosen. Admins are exempt from the team check.

To edit it, run an operation on it, or link an enrichment destination, a user needs the Member role or higher and the Editor team permission on that datastore, through at least one of the teams the datastore belongs to.

To delete it, or to unlink its enrichment destination, a user needs the Admin role. No team permission is consulted.

See Also¶