refactor(proposal): use openapi plugin

[emigun]

Description

Use openapi plugin in proposal module

Motivation

Less clutter in code and less risk for inconstensies between openapi spec and the actual behaviour.

Fixes

Related to #1590

Changes:

Removed all @ApiProperty decorators in proposal module.

The first commit doesn't change the openapi spec. The second commit, which touches three fields, does make some changes which we can discuss.

Tests included

• Included for each change/fix?
• Passing?

Documentation

• swagger documentation updated (required for API changes)
• official documentation updated

[emigun]

There are two commits. The first commit doesn't change anything in the swagger spec. The second one does, for proposal.schema.ts.

For field metadata:
Is it on purpose that the type in ApiProperty is MongooseSchema.Types.Mixed? Seems more reasonable to just have object , for the api users. Also added a default value.

For field parentProposalId :
Changed to string | null since it is nullable, I set the default value to null. Also, changed to optional field because it has a default anyway? What would the point be of having a default if it is required?

For field type:
Same here, changed to optional field since there is a default and I set the default. It is of course possible to only have the default in the ApiProperty, but probably not any real practical difference on setting it?

[nitrosx]

For field metadata:

Is it on purpose that the type in ApiProperty is MongooseSchema.Types.Mixed? Seems more reasonable to just have object , for the api users. Also added a default value.

I do not know why we set it to this type. I agree that using Object is easier. Could you please try switching it to object and verify that all the test pass?

For field parentProposalId :

Changed to string | null since it is nullable, I set the default value to null. Also, changed to optional field because it has a default anyway? What would the point be of having a default if it is required?

OK for the type. I would make required in the schema as you have the default value. It is optional in the dto.

For field type:

Same here, changed to optional field since there is a default and I set the default. It is of course possible to only have the default in the ApiProperty, but probably not any real practical difference on setting it?

Same as parentPRoposalId, optional in the dto, but required in the schema set to the default value.

[emigun]

For field metadata:

Is it on purpose that the type in ApiProperty is MongooseSchema.Types.Mixed? Seems more reasonable to just have object , for the api users. Also added a default value.

I do not know why we set it to this type. I agree that using Object is easier. Could you please try switching it to object and verify that all the test pass?

It is already object since I removed the ApiProperty decorator. The openapi plugin will read the Record type.

For field parentProposalId :

Changed to string | null since it is nullable, I set the default value to null. Also, changed to optional field because it has a default anyway? What would the point be of having a default if it is required?

OK for the type. I would make required in the schema as you have the default value. It is optional in the dto.

I have looked around a bit on the web and it seems the normal way is to not use required when you have a default.

parentProposalId and type are a bit different in that parentProposalId had required: false in the Prop but type had required: true in the Prop decorator. None of them had a ? on the field. Perhaps just drop required on both of them? Without a ? on the property it should be in the required list in the swagger.