287 results found

1. Change streams and Triggers for Time Series Collections

   Add Change streams and Trigger capabilities to Time Series Collections.
   Current Limitations don't allow this.
   https://docs.mongodb.com/manual/core/timeseries/timeseries-limitations/#change-streams

   19 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  ·  3 comments  ·  Change Streams  ·  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

2. Please report mixed-type numeric _id fields in $merge stage error

   Posting this idea at the request of one of the Jira users. You can find more technical details about this in the Jira issue:

   https://jira.mongodb.org/browse/SERVER-61613

   The gist of it is that I may have two collections, b2 and b3, that are not distinguishable in the Mongo Shell, like this:

   db.b2.find()
   
   [
   
     { _id: 1, created: ISODate("2021-11-18T23:16:33.149Z") },
   
     { _id: 2, created: ISODate("2021-11-18T23:16:33.149Z") }
   
   ] 
   
   db.b3.find()
   
   [
   
     { _id: 1, created: ISODate("2021-11-18T22:53:02.113Z") },
   
     { _id: 2, created: ISODate("2021-11-18T22:53:02.113Z") }
   
   ] ```
   
   When I merge each into a collection `pg` with this syntax:
   
   

   db.pg.aggregate([{$merge: {into: "b3", whenMatched: "merge", whenNotMatched: "fail"}} ]);
   ```

   , it reports a cryptic message:

   MongoServerError: $merge failed to update the matching document, did you attempt to modify the id or the shard key? :: caused by :: Performing an update on the path 'id' would modify the immutable field '_id '

   The pg collection is just an example that in real life is a an aggregation stage before $merge.

   The underlying issue is that b2._id is BSON int and b3._id is BSON double, which is not visible in Mongo Shell, and that Mongo DB server fails to recognize numeric types that would work just fine in other comparisons, like queries.

   Please report an error or a warning that _id fields in merged collections are of different numeric types, so it would be clear what the problem is, which will save people a lot of time trying to figure out why the type of _id is being changed.

   Given that _id is immutable, people would have to drop the collection and recreate it, which may be quite tricky for large databases. If there was a tool to do that or if the server would recognize compatible numeric values and report the error only when numeric types cannot be coalesced, it would also be helpful.

   Posting this idea at the request of one of the Jira users. You can find more technical details about this in the Jira issue:

   https://jira.mongodb.org/browse/SERVER-61613

   The gist of it is that I may have two collections, b2 and b3, that are not distinguishable in the Mongo Shell, like this:

   db.b2.find()
   
   [
   
     { _id: 1, created: ISODate("2021-11-18T23:16:33.149Z") },
   
     { _id: 2, created: ISODate("2021-11-18T23:16:33.149Z") }
   
   ] 
   
   db.b3.find()
   
   [
   
     { _id: 1, created: ISODate("2021-11-18T22:53:02.113Z") },
   
     { _id: 2, created: ISODate("2021-11-18T22:53:02.113Z") }
   
   ] ```
   
   When I merge each into a collection `pg` with this syntax:
   
   

   db.pg.aggregate([{$merge: {into: "b3", whenMatched: "merge", whenNotMatched: "fail"}} ]);… 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  ·  Indexes  ·  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

3. multiple centersphere as a geometry for geowithin

   im looking at one of my queries that a system regularly runs and some times we look for records that are within up to 250 different centerspheres, i wornder if we could enable, like geowithin has the ability to support multiple poligons, we could enable multiple centerspheres ,
   
   
$match: {{'location':{
"$geoWithin" : {
"$centerSphere" : [[ 14.4321, -9.4321], 2.5232135647961246e-05]
}
}}, {'location':{
"$geoWithin" : {
"$centerSphere" : [[ 14.4321, -9.4321], 2.5232135647961246e-05]
}
}}, ...}


   we could do :
   ```
   $match: {'location':{
   "$geoWithin" : {
   "$centerSpheres" : [
   [[ 14.4321, -9.4321], 2.5232135647961246e-05] ,
   [[ 14.4321, -9.4321], 2.5232135647961246e-05],
   ...
   ]

       } 
   }}
   

   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  ·  Query and Aggregation Pipeline  ·  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

4. There is a specific collection that I need more performance than others. Is there a way to assign more ram/memory to a specific collection?

   There is a specific collection that I need more performance than others. Is there a way to assign more ram/memory to a specific collection?

   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  ·  Performance  ·  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

5. Unique index in sharded cluster

   For enforcing uniqueness in a sharded cluster, the officially recommended approach provided here https://docs.mongodb.com/manual/tutorial/unique-constraints-on-arbitrary-fields/#std-label-shard-key-arbitrary-uniqueness is simplistic and in production environment it brings non-trivial amount of work. Some considerations:

   1. Ephemeral issues might cause inconsistencies between the two collections (for example, unique index collection update succeeded but not the main collection) and make some unique keys not useable.
   2. There are many changes needed (we're using ORM Mongoose, there are many hooks for it to change) for enforce this universally.

   What we ended up doing is to use distributed ephemeral locks (a TTLed MongoDB collection) to lock on the unique keys before adding to the collection. Getting this correct / verifying its correct is non-trivial.

   For enforcing uniqueness in a sharded cluster, the officially recommended approach provided here https://docs.mongodb.com/manual/tutorial/unique-constraints-on-arbitrary-fields/#std-label-shard-key-arbitrary-uniqueness is simplistic and in production environment it brings non-trivial amount of work. Some considerations:

   1. Ephemeral issues might cause inconsistencies between the two collections (for example, unique index collection update succeeded but not the main collection) and make some unique keys not useable.
   2. There are many changes needed (we're using ORM Mongoose, there are many hooks for it to change) for enforce this universally.

   What we ended up doing is to use distributed ephemeral locks (a TTLed MongoDB collection) to lock on the unique keys before adding… 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  ·  Sharding  ·  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

6. $populate stage

   Please provide a $populate stage that allows to resolve single referenced documents.
   Internally it could use the combination of $lookup and $unwind:

   https://stackoverflow.com/questions/41482559/how-to-return-single-object-instead-of-array-in-lookup-of-mongodb

   Related:

   https://stackoverflow.com/questions/37793844/mongodb-how-to-resolve-dbref-on-client-side

   https://jira.mongodb.org/browse/SERVER-22497

   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  ·  Query and Aggregation Pipeline  ·  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

7. Reserve connections to admin users

   When the max number of connections is reached, no one can login to the database until some connections are closed or a failover is triggered (killing all the connections).

   The admin users should have a few reserved connections so that they can login to the database and take actions, like kill some connections.

   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  ·  Administration  ·  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

8. Mongo replicaset init sync issue

   When we have large size mongo replica set, we may have to take out each nodes for maintenance for few hrs or days.

   In that case we have to increase size of Oplog to keep several days of transactions to resync nodes after maintanance.

   If the RS headroom falls below oplog window, then we have blow away data and do init sync to add node back after maintanence.

   The problem with very large size Oplog, will slow down any Change Stream process. Also it will occupy un neccasary space within collections.

   Can mongo offer alternative way to constantly dump oplog data to local file system? Then we can use this data to re-apply transactions, to sync failed nodes, instead of doing init sync. Some thing similar to archichive log mechanism for redo log, Oracle uses.

   This will avoid init sync issue for very large replica sets.

   Thanks
   Rama Arumugam

   When we have large size mongo replica set, we may have to take out each nodes for maintenance for few hrs or days.

   In that case we have to increase size of Oplog to keep several days of transactions to resync nodes after maintanance.

   If the RS headroom falls below oplog window, then we have blow away data and do init sync to add node back after maintanence.

   The problem with very large size Oplog, will slow down any Change Stream process. Also it will occupy un neccasary space within collections.

   Can mongo offer alternative way to constantly dump oplog… 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  ·  Replication  ·  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

9. Shard Drain/ Removal issue

   If we have more shards, and if want to remove few shards (more than 1), we use below command.

   db.adminCommand( { removeShard : "Shardname" } )

   Ex, if I have Shard 1, 2, 3, 4, 5. want to remove Shard 2 & 5.

   I want to remove one shard at a time to minimize impact to users , then want to remove, say Shard 2, then want to remove Shard 5.

   If we do this, some chunks from Shard#2 also get moved to "Shard#5", which is suppose to removed later. This causes Shard#5 chunk size increase. Then takes more time.

   Offcourse we can remove more than 1 shard in parellel (from version 4.4 onwards), but it may cause performance issue since balancer will be busy migrating chunks.

   So, it will be good, mongo an add new command, "mark the shards to be removed". No new chunks should move to these shards. Then we can remove 1 shard at time, to reduce performance impact.

   Thanks
   Rama

   If we have more shards, and if want to remove few shards (more than 1), we use below command.

   db.adminCommand( { removeShard : "Shardname" } )

   Ex, if I have Shard 1, 2, 3, 4, 5. want to remove Shard 2 & 5.

   I want to remove one shard at a time to minimize impact to users , then want to remove, say Shard 2, then want to remove Shard 5.

   If we do this, some chunks from Shard#2 also get moved to "Shard#5", which is suppose to removed later. This causes Shard#5 chunk size increase. Then takes more time.

   … 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  ·  Sharding  ·  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

10. Rename an existing index

    Allow for the possibility of renaming an existing index, without having to drop and recreate it.

    Let us say a unique index exists in production, it might not be possible to safely drop it. Yet the index name might not be ideal.

    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

    1 comment  ·  Indexes  ·  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

11. Implement read-only fields and documents in database

    I haven't tracked down this functionality yet, so excuse me if it is already implemented.

    As a developer and system administrator I came to a dilemma how to prevent myself to make changes to documents.

    I can limit myself as a programmer, but as a administrator I can always logon to console and make changes ''by hand''.

    I was thinking of read-only field type, which once set, could not be updated nor removed from document (although backup and restore is the first problem which comes to mind). This limit should be set on a database level. Read-only field could typically hold some computed hash value, which would guaranty that the field or document was not changed in any way.

    There could also be collections with read-only documents. For example when ''read-only-document'' field is set, database would prevent any updates (deletes) to document. Although more problems can arise here. Like how to remove outdated documents or move them to archive collection.

    by
    TheR

    I haven't tracked down this functionality yet, so excuse me if it is already implemented.

    As a developer and system administrator I came to a dilemma how to prevent myself to make changes to documents.

    I can limit myself as a programmer, but as a administrator I can always logon to console and make changes ''by hand''.

    I was thinking of read-only field type, which once set, could not be updated nor removed from document (although backup and restore is the first problem which comes to mind). This limit should be set on a database level. Read-only field could typically… 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  ·  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

12. The ability to perform a quick rollback or rewind of the database

    This is along the lines of a flashback, to a previous point in time say from a very impacting change to data.. A large delete or data modification event. This avoids the need to take a complete outage for hours and hours restoring TBs of data and re-applying change logs. Would be great if this could be done to the granularity of a single or multiple collections too. This could use the oplogs present locally or in the oplog store.

    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  ·  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

13. `Blocking` Flag for Explain Output

    It's not always obvious which aggregation stages are blocking or non-blocking when viewing explain output for an aggregation command. It would be helpful to include a blocking flag for each stage of an aggregate command in its explain output.

    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  ·  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

14. restricted mode for database

    database in restricted mode can very helpful .. so we can carry out , lock users out, rebuild indexes, compact and other admin tasks.

    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

    2 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

15. Support for converting between UUID and String

    It would be nice to have UUID support for $convert and $toString functions - and maybe also having a new $toUuid function added.

    We have documents with UUIDs stored as UUIDs, and others where they are stored as Strings - and need to $lookup a document with an UUID type _id from a document where that uuid is stored as a String. As far as I can tell that is currently not possible.

    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  ·  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

16. Allow changing config values without restart

    It would be great if configuration changes could be effected without needed to restart nodes.

    For example, audit filter, enabling/disabling different security mechanisms.

    This would be especially useful for Atlas and clients with large clusters where restarts will cause a performance deficit due to cold cache after node restarts.

    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  ·  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

17. Tiered TTL for time series collection based on granularity

    Currently time series collections have a single TTL across all inherent granularities. It would be great to specify a TTL for each granularity. For example:

    For seconds: 1 week
    For hours: 1 month
    Others: never

    Course information should be held longer than finer information in some cases - currently they all fall under the main TTL specified.

    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  ·  Time Series  ·  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

18. Provide straightforward syntax for 1-to-1 joins in aggregation

    The syntax for joins that bring back multiple documents from foreign collections is very straightforward and yields exactly what one would expect, but simple joins that are bread and butter in SQL require very convoluted and expensive to run syntax.

    Consider a product database that has products, categories and reviews collections. Each product has a unique category and may have multiple reviews. Getting all reviews in an aggregation is very straightforward (top stage), but getting categories, similar to SQL, is as convoluted as it gets (bottom stage).

    db.products.aggregate(
    [
        //
        // Document aggregates naturally aggregate foreign documents
        // into the primary document.
        //
        {$lookup: {
          from: "reviews",
          localField: "_id",
          foreignField: "product_id",
          as: "reviews"
        }},
    
        //
        // A simple join that is supposed to bring a couple of fields
        // into the primary document translates into this convoluted
        // syntax just to get those two fields.
        //
        {$lookup: {
          from: "categories",
          let: {category_id: "$category"},
          pipeline: [
            {$match: {
                $expr: {$eq: ["$_id", "$$category_id"]}
            }},
            {$project: {
                _id: 0,
                cat_name: "$category",
                cat_description: "$description"
            }}
          ],
          as: "category_details"
        }},
        {$replaceRoot: {
          newRoot: {
            $mergeObjects: [
              "$$ROOT", {$arrayElemAt: ["$category_details", 0]}
            ]
          }
        }},
        {$project: {
            category_details: 0
        }}
    ])
    

    Notice that keeping category.category and category.description in products, the noSQL-way, isn't an option because updating 10000's of products when category or description change is just not a good idea any way one looks at it. Denormalization is useful in many noSQL scenarios, but this isn't one of them.

    Having some simple join syntax that would identify the joined collection as a 1-to-1 join and would bring field names and values as if they existed in the primary document, possibly aliased via a projection-like syntax, would be extremely helpful in keeping aggregations readable, keeping data reasonably normalized, and would run much faster because it would be just multiple parallel BSON append calls when constructing aggregation results documents.

    Data for the query:

    products:
    
{"_id":{"$oid":"6140e6c6dfe7b9d6e597d07e"},"name":"Product A","category":1,"price":111}
{"_id":{"$oid":"6140e6c6dfe7b9d6e597d07f"},"name":"Product B","category":2,"price":222}
{"_id":{"$oid":"6140e6c6dfe7b9d6e597d080"},"name":"Product C","category":1,"price":333}

    categories:
    
{"_id":1,"category":"Clothing","description":"All kinds of clothing"}
{"_id":2,"category":"Electronics","description":"Cool gadgets"}

    reviews:
    
{"_id":{"$oid":"6140e7cadfe7b9d6e597d08a"},"product_id":{"$oid":"6140e6c6dfe7b9d6e597d07e"},"review":"Product A is great","rating":4}
{"_id":{"$oid":"6140e813dfe7b9d6e597d090"},"product_id":{"$oid":"6140e6c6dfe7b9d6e597d07f"},"review":"This product is horrible","rating":1}
{"_id":{"$oid":"6140e8eff4ff76778b48ba88"},"product_id":{"$oid":"6140e6c6dfe7b9d6e597d07f"},"review":"This product is not the best, but usable","rating":2}


    The syntax for joins that bring back multiple documents from foreign collections is very straightforward and yields exactly what one would expect, but simple joins that are bread and butter in SQL require very convoluted and expensive to run syntax.

    Consider a product database that has products, categories and reviews collections. Each product has a unique category and may have multiple reviews. Getting all reviews in an aggregation is very straightforward (top stage), but getting categories, similar to SQL, is as convoluted as it gets (bottom stage).

    db.products.aggregate(
    [
        //
        // Document aggregates naturally aggregate foreign documents
        // into

    … 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

    3 comments  ·  Query and Aggregation Pipeline  ·  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

19. MultiTenant Abstraction

    Just as a time-series collection in MongoDB 5.0 abstracts the underlying implementation of the bucketing pattern, customers who implement a multi-tenant model through separate databases per tenant run into the issue of too many dhandles and would benefit from an abstraction of the implementation of a collection-with-discriminator-field - they would be able to meet their internal compliance requirement of separate databases per customer, and would have minimal changes to their code.

    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  ·  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

20. Retrywrite error fixed in Mongodb 4.4

    We have test the retry write in Atlas by using mongodb java driver in Mongodb 4.4 cluster. The error is similar to SERVER-53624(https://jira.mongodb.org/browse/SERVER-53624). The supporter respond the error will fix in Mongodb 5.0. We hope this error can also fixed in Mongodb 4.4

    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  ·  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