73 results found

1. Show Cursor Not Found Errors (telemetry)

   We have a lot of cursor not found errors and currently there isn't an easy way to locate them at the Atlas integrated monitoring.
   It would be nice to have this feature.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Monitoring and Metrics  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. Show Index Error on UI

   When creating an index on your UI, if the index creation gives an error, the error doesn't show on the UI, for example if you have a field of type string, and have a value longer than 1024 bytes, and try to create a normal index on this field, the UI will tell you the index it's been creating successfully, but when you go to your collection and see your indexes, this will not appear, but when you create it on the MongoDB console, it gives the following error. It would be nice to have this error shown on the UI

   WiredTigerIndex::insert: key too large to index, failing 2864 { : "TXQAAE10ABdjb20uY2F1Y2hvLm5hbWluZy5RTmFtZVMACF9jb250ZXh0TXQAJ2phdmF4Lm5hbWluZy5zcGkuQ29udGludWF0aW9uRGlyQ29udGV4dFMAA2NwZU10ACNqYXZheC5uYW1pbmcuQ2Fubm..." }

   When creating an index on your UI, if the index creation gives an error, the error doesn't show on the UI, for example if you have a field of type string, and have a value longer than 1024 bytes, and try to create a normal index on this field, the UI will tell you the index it's been creating successfully, but when you go to your collection and see your indexes, this will not appear, but when you create it on the MongoDB console, it gives the following error. It would be nice to have this error shown on the… more

   16 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Indicate operation errors already in the plan phase

   This idea originates from my original bug report: https://github.com/mongodb/terraform-provider-mongodbatlas/issues/284

   Changing the name of an existing custom_db_role is currently not possible without ending in an error in the apply step. The plan for a name change currently indicates the replacement due to the name change:

   # module.versioner.mongodbatlas_custom_db_role.this must be replaced
   -/+ resource "mongodbatlas_custom_db_role" "this" {
       ~ id         = "someid" -> (known after apply)
           project_id = "5c860ed2a6f2396cd47f4785"
       ~ role_name  = "old_name" -> "newName" # forces replacement
   

   Applying this results in the following error:

   Error: error deleting custom db role (mongoversioner): DELETE https://cloud.mongodb.com/api/atlas/v1.0/groups/projectid/customDBRoles/roles/old_name: 409 (request "Conflict") Deleting specified custom role would leave the following users without a role: someuser.

   I understand that this is not possible directly without unassigning the user, but some indication for these kinds of issues already in the plan phase would make things much easier to handle.

   This idea originates from my original bug report: https://github.com/mongodb/terraform-provider-mongodbatlas/issues/284

   Changing the name of an existing custom_db_role is currently not possible without ending in an error in the apply step. The plan for a name change currently indicates the replacement due to the name change:

   # module.versioner.mongodbatlas_custom_db_role.this must be replaced
   -/+ resource "mongodbatlas_custom_db_role" "this" {
       ~ id         = "someid" -> (known after apply)
           project_id = "5c860ed2a6f2396cd47f4785"
       ~ role_name  = "old_name" -> "newName" # forces replacement
   

   Applying this results in the following error:

   Error: error deleting custom db role (mongoversioner): DELETE https://cloud.mongodb.com/api/atlas/v1.0/groups/projectid/customDBRoles/roles/old_name: 409 (request "Conflict") Deleting specified custom role would leave the… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Terraform Provider  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

4. Alert when a snapshot restore succeeds/fails

   Simply send an email alert when a restore finishes (or errors).

   This is important for us because we run a restore (from prod to qa) every weekend and it takes over 14 hours. If it fails, we need to know so we can quickly kick it off again before Monday. Otherwise the QA team will be dead in the water.

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Backup  ·  Delete…  ·  Admin →
   completed  ·  AdminBenjamin Cefalo (Director, Product Management, MongoDB) responded

   In Atlas, you can now create alerts related to backup.

5. Atlas Shard Management

   Currently the Atlas UI only presents options for how many shards a cluster can have.

   Putting in a suggestion to perhaps allow similar functionality / features to Cloud Manager's shard management as shown : https://docs.cloudmanager.mongodb.com/tutorial/manage-data-sharding/#manage-sharded-collections

   6 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

6. API - Version 2

   We saw that the api version is now in v2 for some resources (as clusters) - https://www.mongodb.com/docs/atlas/reference/api-resources-spec/v2/#tag/Clusters/

   We tried to change some App services functions from v1 to v2, but ended resulting in some errors (or needing to add more parameters than the original one - in version 1).
   Using version 1, we only inform what we need to change ("instanceSize") plus the providerName.

   to use version 2, we need to inform all this parameters (if it's a replica-set. If it is a sharding we also need to inform the numShards):
   "replicationSpecs":[{"regionConfigs":[{"electableSpecs":{"instanceSize":"M10","nodeCount":"3"},"priority":"7","providerName":"GCP","regionName":"CENTRAL_US"}]}]}

   What I need to change is only the "instanceSize":"M10", but I need to use IN A PATCH all this other parameters. It doesn't make any sense to need to inform all of this if I'm using a PATCH (it is not a PUT, it should work fine receiving only what I'm about to change)

   It would be great if this could be fixed so it would work just receiving what we want to change, or at least just receiving the parameters that v1 needed.

   We saw that the api version is now in v2 for some resources (as clusters) - https://www.mongodb.com/docs/atlas/reference/api-resources-spec/v2/#tag/Clusters/

   We tried to change some App services functions from v1 to v2, but ended resulting in some errors (or needing to add more parameters than the original one - in version 1).
   Using version 1, we only inform what we need to change ("instanceSize") plus the providerName.

   to use version 2, we need to inform all this parameters (if it's a replica-set. If it is a sharding we also need to inform the numShards):
   "replicationSpecs":[{"regionConfigs":[{"electableSpecs":{"instanceSize":"M10","nodeCount":"3"},"priority":"7","providerName":"GCP","regionName":"CENTRAL_US"}]}]}

   What I need to change is only the… more

   38 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Administration API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

7. Standardize case for region values

   Depending on the resource, the case for the region value changes from uppercase with underscores (US_ EAST _1) to lowercase with dashes (us-east-1). This presents an unnecessary challenge when working with the provider. It would be much cleaner, easier to work with, and prone to fewer errors if all resources accepted us-east-1.

   6 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   declined  ·  3 comments  ·  Terraform Provider  ·  Delete…  ·  Admin →

8. Display the error code within Atlas UI if an index fails

   When creating an index via the Atlas UI, the interface currently does not display the error code if the index build fails. This lack of visibility makes it difficult for customers to understand the cause of failure without contacting support.

   This limitation is particularly impactful for unique index creation. In these cases, mongod validates constraints only at the end of the build process. If duplicate keys are found, the index build fails after consuming significant time and resources — but the Atlas UI does not surface the underlying E11000 duplicate key error (or other relevant error codes).

   If I submit an index creation from mongosh, it will display that "index build has failed" along with the error code as shown below.

   [primary] samplemflix> db.comments.createIndex({ email: 1 }, { unique: true })
   MongoServerError[DuplicateKey]: Index build failed: b691a5ae-895b-42cf-bcf6-7d0f751b0c4f: Collection samplemflix.comments ( b1d9a6f4-5e6a-44ce-ac6a-b6351c73b952 ) :: caused by :: E11000 duplicate key error collection: samplemflix.comments index: email1 dup key: { email: null }

   If the Atlas UI were able to display the specific error code and message directly, application teams would immediately see that the failure was due to duplicate keys (or another constraint violation), saving time and reducing dependency on support.

   When creating an index via the Atlas UI, the interface currently does not display the error code if the index build fails. This lack of visibility makes it difficult for customers to understand the cause of failure without contacting support.

   This limitation is particularly impactful for unique index creation. In these cases, mongod validates constraints only at the end of the build process. If duplicate keys are found, the index build fails after consuming significant time and resources — but the Atlas UI does not surface the underlying E11000 duplicate key error (or other relevant error codes).

   If I submit… more

   •  

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Data Explorer  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

9. Live Migrate modal: Allow users to point and click to select another Atlas source cluster

   It is often practical to Live Migrate from one Atlas cluster to another Atlas cluster (e.g. to create another staging environment if backups are not enabled on the source, or migrate a production/staging environment to another dedicated project with minimal downtime).

   Currently, the Live Migrate modal requires connection details from the source cluster, including the hostname of the primary, port, etc. Validation will fail if there are typos/errors in these inputs.

   It would be easier to have a point-and-click option to "Migrate from another Atlas cluster" -- it could be a drop-down menu with names of other Atlas clusters in the project/organization that could be selected. The required connection parameters could then be automatically populated based on the particular cluster. A temporary user with the required permissions could even be created and then removed after the migration is complete.

   This could make it easier to start Live Migrations between Atlas clusters, and avoid the need for the user to locate and confirm specific source connection requirements.

   It is often practical to Live Migrate from one Atlas cluster to another Atlas cluster (e.g. to create another staging environment if backups are not enabled on the source, or migrate a production/staging environment to another dedicated project with minimal downtime).

   Currently, the Live Migrate modal requires connection details from the source cluster, including the hostname of the primary, port, etc. Validation will fail if there are typos/errors in these inputs.

   It would be easier to have a point-and-click option to "Migrate from another Atlas cluster" -- it could be a drop-down menu with names of other Atlas clusters… more

   12 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

10. Show queries that exceeded maxTimeMs in the Atlas Profiler

    We had some queries hit the maxTimeMS and fail. We had to download the log files for visibility into those errors. That is info that we would love to see in the Profiler!

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Performance Advisor  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

11. Possibility to change 'frequency_type' of snapshot backup policy item via Terraform

    Hi,

    I’m facing an issue about Snapshot Backup Policy creation/modification via Terraform ( FYI, I open a case to the support of MongoDB  https://support.mongodb.com/case/00668262). Let me explain :

    When I want to create a MongoAtlas Cluster via terraform, I want to apply a custom Snahsphot Backup Policy with ONLY 2 items during the creation of the cluster :
    N° Item Frequency type Frequency Retention
    0 Daily 1 7 Days
    1 Weekly 1 (Saturday) 4 weeks

    However, during the creation of the mongo atlas cluster, I can see an error
    Error: Error applying plan:

    1 error occurred:
    * module.clustercontrib.module.dpjmongoatlas.module.tfmodule-gcp-mongo-atlas-cluster.mongodbatlascloudprovidersnapshotbackuppolicy.snapshotbackup: 1 error occurred:
    * mongodbatlascloudprovidersnapshotbackuppolicy.snapshot_backup: error updating a Cloud Provider Snapshot Backup Policy: PATCH https://cloud.mongodb.com/api/atlas/v1.0/groups/XXXXXXXXXXXXXXXXX/clusters/contrib/backup/schedule: 400 (request "Bad Request") The frequency type of a policy item must not be changed.

    Indeed, during the creation of the MongoAtlas cluster, MongoAtlas apply the default Snapshot Backup Policy first (with 4 items hourly, daily, weekly, monthly) and after try to apply the custom snapshot backup policy I want (described in the terraform code). But, as we can see above, it seems impossible to change the frequency_type of an existing policy’s item…

    To resume clearly with this spreadsheet :
    N° Item Frequencytype of default policy Frequencytype of custom policy I want COMMENT
    0 Hourly Daily KO (because The frequency type of a policy item must not be changed)

    1 Daily Weekly KO (because The frequency type of a policy item must not be changed)

    2 Weekly NOTHING
    3 Monthly NOTHING

    Can we purpose a evolution to have the possibilty to modify the frequency_type of an existing policy item via Terraform/API?

    Regards,

    Hi,

    I’m facing an issue about Snapshot Backup Policy creation/modification via Terraform ( FYI, I open a case to the support of MongoDB  https://support.mongodb.com/case/00668262). Let me explain :

    When I want to create a MongoAtlas Cluster via terraform, I want to apply a custom Snahsphot Backup Policy with ONLY 2 items during the creation of the cluster :
    N° Item Frequency type Frequency Retention
    0 Daily 1 7 Days
    1 Weekly 1 (Saturday) 4 weeks

    However, during the creation of the mongo atlas cluster, I can see an error
    Error: Error applying plan:

    1 error occurred:
    * module.cluster… more

    28 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Terraform Provider  ·  Delete…  ·  Admin →
    completed  ·  AdminMelissa (Lead Product Manager, MongoDB) responded

    The Cloud Backup policy has been completely reworked as of provider version 1.0.0, with a few more fixes in 1.0.1 (coming shortly). This should address the pain points that have been raised here and elsewhere.

12. Show Mongos Connection Number in Overview.

    Currently, the connection number shown in Overview is shard connection, it is the connection from Mongos to Mongod, which should usually be lower than the Mongos connection.
    The connection limit for MongoDB is referring to Mongos connection which should be shown in overview or otherwise very misleading when we received connection % alert.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Monitoring and Metrics  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

13. Cluster Termination Protection

    It is possible to quickly delete an entire cluster, for example through terraform, if you're not careful.

    It would be great to have a "Termination Protection" feature that can only be disabled in the Admin UI and not via the public APIs.

    In terraform I could then enable it like so

    
    
    resource "mongodbatlas_cluster" "my_cluster" {
      enable_delete_protection = true
    }
    

    When I would run terraform destroy the cluster should not be destroyed and instead the API returns an error saying that the Cluster has Termination Protection enabled. If I want to disable it, I can login to the Admin UI, select the cluster, then click "Disable Termination Protection" somewhere.

    AWS has a similar feature where EC2 instances can have Termination Protection enabled. With Termination Protection enabled they cannot be deleted through code, even CloudFormation will throw an issue.

    It is possible to quickly delete an entire cluster, for example through terraform, if you're not careful.

    It would be great to have a "Termination Protection" feature that can only be disabled in the Admin UI and not via the public APIs.

    In terraform I could then enable it like so

    
    
    resource "mongodbatlas_cluster" "my_cluster" {
      enable_delete_protection = true
    }
    

    When I would run terraform destroy the cluster should not be destroyed and instead the API returns an error saying that the Cluster has Termination Protection enabled. If I want to disable it, I can login to the Admin UI, select… more

    66 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    9 comments  ·  Other  ·  Delete…  ·  Admin →
    completed  ·  AdminPhuong-Thao (Sue) (Admin, MongoDB) responded

    You can now set "Termination Protection" for your Atlas cluster.   For more information, see https://www.mongodb.com/docs/atlas/cluster-additional-settings/#termination-protection

14. disabling snapshots

    When we disable de snapshot from one cluster, the following message is shown in the same page but it does not appear at the page that shows the changes that are being made

    It would be better if this message were also at the second page (as image uploaded)

    Please Note: This action is irreversible. Turning off or altering your type of backup will delete all of your existing snapshots immediately. If you want to keep old versions of your data, visit the backup dashboard and download your snapshots

    •  

    •  

    4 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

15. Show date in UI DB Stats axes

    Show date in UI DB Stats axes

    Currently the x-axis of DB Stats charts do not show dates, making it difficult to interpret the range of time displayed in the chart.

    For example, you can see in the date menu shown in the attached image that the chart range is over 4 days, but this is not apparent in the x-axis of each chart -- the x-axis only shows one reference time of 07:00.

    It would be more helpful if the axis showed a reference date in addition to the time, and ideally a couple dates so that it is easy to understand the time range of the chart.

    Show date in UI DB Stats axes

    Currently the x-axis of DB Stats charts do not show dates, making it difficult to interpret the range of time displayed in the chart.

    For example, you can see in the date menu shown in the attached image that the chart range is over 4 days, but this is not apparent in the x-axis of each chart -- the x-axis only shows one reference time of 07:00.

    It would be more helpful if the axis showed a reference date in addition to the time, and ideally a couple dates so that it is… more

    •  

    5 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Monitoring and Metrics  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

16. Index creation should not be possible via UI if maximum number of indexes exist in the ollections

    Index creation should not be possible via UI if maximum number of indexes exist in the collections. Or a warning should be shown

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Data Explorer  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

17. Please allow for showing most recently added to collection first.

    Right now collections are only shown first added first. I think it would be useful to be able to look at the last added first.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Data Explorer  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

18. Support Google IdP for OIDC Workforce Federation

    The Atlas supports federated login with external Identity Providers via OIDC (https://www.mongodb.com/docs/atlas/workforce-oidc/) for authenticating human users in tools like mongosh or Mongo Compass.

    Unfortunately the OIDC login doesn't work with the GCP IdP: OAuth2 clients in Google IdP always have a client secret (even clients considered as "public"). There is no way to specify the client secret in Atlas UI in the Workload Federation configuration and this leads to "invalidrequest (clientsecret is missing.)" error returned from the IdP as it always expects a client secret to be present.

    The support of an optional client secret in the Atlas Workload Federation configuration will enable the integration with the GCP IdP.

    The Atlas supports federated login with external Identity Providers via OIDC (https://www.mongodb.com/docs/atlas/workforce-oidc/) for authenticating human users in tools like mongosh or Mongo Compass.

    Unfortunately the OIDC login doesn't work with the GCP IdP: OAuth2 clients in Google IdP always have a client secret (even clients considered as "public"). There is no way to specify the client secret in Atlas UI in the Workload Federation configuration and this leads to "invalidrequest (clientsecret is missing.)" error returned from the IdP as it always expects a client secret to be present.

    The support of an optional client secret in… more

    18 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    planned  ·  4 comments  ·  IAM  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

19. Add support for allowDiskUse when using the Data API

    The Data API doesn't support the allowDiskUse option, leaving no way to get around this error:

    "Failed to aggregate documents: FunctionError: (QueryExceededMemoryLimitNoDiskUseAllowed) Exceeded memory limit for $group, but didn't allow external spilling; pass allowDiskUse:true to opt in"

    12 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Data API  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

20. Show warning when user is configured with access to invalid resources

    When an invalid resource is specified in data plane user's access policy ("grant access to") authentication errors are misleading.

    For Example: if user "John" is limited access to cluster "xo" but cluster is created as "x0" by mistake, when John is authenticated against "x0" we simply get "user not found error" in client.

    If the Atlas UI can highlight the potential error, that cluster "xo" is not found, as cluster cannot be implicitly created. it will save valuable time for developers debugging entitlement issues.

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating