No field type for native Mongo ObjectId's?

As far as I can tell, there’s no nice way to store Mongo’s native ObjectId type… https://docs.mongodb.org/manual/reference/object-id/

If the object exists in the same DB the Relationship type is appropriate:

someRelatedId: { type: keystone.Field.Types.Relationship, ref: 'SomeModelName', ... }

But if the object you’re referring to exists in a different DB you’re forced to use a string field:

someRelatedId: { type: String, ... }

… which works but, of course, stores the value as an arbitrary string and fails to leverage the underlying validation of the ObjectId type.

I half expected this would work:

someRelatedId: { type: keystone.mongoose.Types.ObjectId, ref: 'SomeModelName', ... }

… but apparently types must extend the Keystone Type class.

[mxstbr]

It’s a lot of work to maintain a large open source project, and being focussed is one of the most important aspects of managing one. We had 600 open issues, of which we closed ~400 by simply moving all feature requests to Product Pains and another ~100 were duplicates or fixed.

This means two very beneficial things:

1. We’re hyper aware of which bugs exist in KeystoneJS and need to be fixed (not possible with 600 open issues, very possible with 100 open ones)
2. We know which features the community wants most since we you can upvote them (not possible with Github issues)

Which combined mean that in the long run, KeystoneJS will be a lot better off than if we didn’t do this. 👍

[rturk]

@mxstbr makes no sense to close issues just clear the tracker. Should only close when resolved or decided not be fixed/changed