Accessible entity ids in relational custom fields

[Draykee]

Is your feature request related to a problem? Please describe.

Usecase:
We want to add a relation Product to User (called owner) to implement an ownership. For access controll we only need the user id from the product to compare it with the activeUserId of the RequestContext. Right now, the user needs to be eagerly loaded to access the id, therefore it would be awesome if we could just access the id directly from the column in the entity table

Instead of:
product.customFields.owner.id

We could directly access the id via:
product.customFields.ownerId

Describe the solution you'd like

For own entities we can achieve this in TypeORM by adding a relational definition and a defintion of the relation id to an entity:

@OneToOne(() => User, { onDelete: 'CASCADE' })
owner: User; // This will add the column ownerId to the entity

@EntityId()
ownerId: ID; // With this we can directly access the data from the column

This TypeORM definition should be created by a custom fields configuration like this:

config.customFields.Product.push({
            name: 'owner',
            nullable: true,
            type: 'relation',
            entity: User,
            public: false,
            readonly: true,
            withId: true, // a option like this could add the extra definition
            
        });

To prevent breaking changes, the option shall be false by default for the next minor versions.

[michaelbromley]

Hey! It took me a while to get around to this but yes, this is a very good suggestion.

[dlhck]

This is a great feature request. Very interesting for multi-vendor applications or larger teams with defined ownership structure on data management.

[michaelbromley]

This is proving much more difficult to implement correctly than I had imagined. I spent a couple of hours trying to debug the problems but I'm not there yet. The WIP is in the branch linked above. I need to return to this when I have more time to dedicate to debugging it.

[michaelbromley]

Moved to the v3.2 milestone because more time is needed to resolve the issues in the WIP branch.