What is the problem that needs to be solved? Ops Manager's Org ID/Org Name/Project Name attributes needs to be added to Project (GET /groups/{PROJECT-ID}/alerts) / Global (GET /globalAlerts) Alerts API calls and Alert Webhooks.

Why is it a problem? (the pain) Ops Manager's Org ID/Org Name/Project Name attributes are currently missed in Project (GET /groups/{PROJECT-ID}/alerts) / Global (GET /globalAlerts) Alerts API calls and Alert Webhooks. Operator who watch Monitoring System (the one that receive Ops Manager Alerts) needs to see Ops Manager's Organization ID/Organization Name/Project Name in order to quickly understand to where that Ops Manager's Alert is related to. Monitoring System (the one that receive the alert from Ops Manager) needs to do additional work for alert received (via GET /groups/{PROJECT-ID} GET /orgs/{ORG-ID} API calls (if possible at all)) in order to resolve Ops Manager's Project ID (which is included into every alert) into Ops Manager's Organization ID/Organization Name/Project Name.

More fine granular OpsManger roles for API CRUD operations

In order to generate API Keys users need some pretty powerful role https://docs.opsmanager.mongodb.com/current/reference/api/org-api-keys/. Same for project API Keys https://docs.opsmanager.mongodb.com/current/reference/api/project-api-keys/.

Our understanding is that user who can create api keys could also self promote themselves to super admins which is something we don't want and would be a security concern to us. (And admins normally have access to far more things than just user mgmt)

Additionally it would be beneficial to pass in an desired api key - e.g. for initial provisioning and give admins the chance to reset/rotate an API Key.

This would boil down two these two request for enhancements:

1. As a user who's logged into Ops Manager, I can generate an API token for myself without having project admin rights
2. As an Ops Manager Admin user, I can pass in a username and desired api key into the OpsManager API

When using Ops Manager UI (I've not checked the API) to declare a MongoDB cluster to be backed up, Ops Manager tries to be a good citizen and check to see if the clusters oplogs are large enough, based on their recent usage to hold at least 3 hours worth of data based on the last 24 hours of usage patterns. if the check fails, the user is prevented from enabling backup and is shown the warning:

"Insufficient oplog size: The oplog window must be at least 3 hours over the last 24 hours for all members of replica set rsa. Please increase the oplog."

There are many use cases where using the last 24 hours of oplog use is not a good indication of future use. For example, a user may deploy a new MongoDB cluster to production, run a job to insert a set of reference data at a very high rate and then use Ops Manager to enable the cluster to be backed up, ready to go live, all in a short space of time (eg. an hour or so). They will likely be prevented from backing up due to the too restrictive and crude check that assumes wrongly that the oplog size is not sufficient. Changing the oplog size, that has already been accurately sized by the user for the expected production workload, just to enable backup, is not the right answer and could be detrimental to the clusters performance from then on.

The enhancement request has multiple parts:
1. Change the error check to just be a warning instead, to allow the user to be informed of a possible problem but allow them to evaluate/accept the risk and continue anyway.
2. Improve the oplog size/duration check algorithm (not sure how)
3. When displaying the oplog size warning saying that the oplog size should be increased, state the minimum size that it should be, based on the check algorithm's results. Otherwise it's a guessing game and the user may have to make multiple attempts to get it right, just to be able to enable backup.

At present if a collection has a default collation configured, sharding such a namespace via Ops Manager results in a failure with the following symptom:

<myCluster_mongos_131> [13:21:17.050] Plan execution failed on step ShardCollections as part of move ShardCollections : <myCluster_mongos_131> [13:21:17.050] Failed to apply action. Result = <nil> : <myCluster_mongos_131> [13:21:17.050] Error calling shardCollection on sh.myColl with key = [[a 1]] : <myCluster_mongos_131> [13:21:14.994] Error executing WithClientFor() for cp=mubuntu:27017 (local=false) connectMode=AutoConnect : <myCluster_mongos_131> [13:21:14.993] Error running command for runCommandWithTimeout(dbName=admin, cmd=[{shardCollection sh.myColl} {key [{a 1}]} {unique false}]) : result={} identityUsed=mms-automation@admin[[MONGODB-CR/SCRAM-SHA-1]][24] : (BadValue) Collection has default collation: collation: { locale: "fr", caseLevel: false, caseFirst: "off", strength: 3, numericOrdering: false, alternate: "non-ignorable", maxVariable: "punct", normalization: false, backwards: false, version: "57.1" }. Must specify collation {locale: 'simple'}


In addition there is no way to specify a default collation if a collection is created via Ops Manager UI.

Please add support of default collation.

When setting a Programmatic API Key in the MongoDB Ops Manager for a given Project, it seems Project Owners are unable after setting the Key to update the IP Whitelist as they require Organization User Admin role to perform such action (screenshot attached).

I guess this makes sense if the same Programmatic API Key is shared between multiple Projects inside the same Organization, but not really if this is applied only to one single Project (i.e. Project Owners should be able to amend the IP Whitelisting of their own API Keys).

I wonder if this could be enhanced in further Ops Manager upgrades.