Inconsistencies in ongoing custom fields specification

[ChernyshevDS]

Hello. I've stumbled across some inconsistencies between Readme description and swagger spec on ongoing master branch (19ac4f4) and some things that I just don't understand, mainly about upcoming custom fields.

project_custom_field_extension describes minArraySize and maxArraySize and plain integers, but readme for 3.1.4 GET Project Extension Service states that they can be null. Only maxArraySize can be null or minArraySize too? What if they are both null?

Same paragraph: there are 6 supported types. In swagger project_custom_field_extension defines additional date type not described in readme.

Custom field can have an array value, so project_custom_field_extension defines defaultValue field as an array of strings. However, topic_custom_field defines custom field value as single nullable string.

Other things, not related to custom fields:

• user_GET defines a oneOf constraint on name and email fields, which renders strangely in swagger. From client's perspective, I think the id field is a required one, because we use it in other endpoints, and name is used for display in client, so i think it should be required too. These fields may contain actual user's email or login, but the client should not rely on that - it treats them as opaque fields.

• extension_item_set - why use the object like { "id": "id_value" } instead of just "id_value"? It's not like you need some other data to establish a relationship between two objects, like assign a user to the topic or set status or label.

Best regards.

[GeorgDangl]

Hey @ChernyshevDS, thank you for raising this!

For the minArraySize part and the date question, we've added a PR: #382

We've also did #383 for the issue with the Swagger spec for the custom fields.

We've also removed the oneOf part in the user_GET model.

As for the last part, why we're requiring to provide an object instead of just a string when setting a value from the extensions. We wanted to be ready for any future needs if we e.g. need to add additional data or properties. So it was easier to directly use an object which could be extended later.

[ChernyshevDS]

@GeorgDangl Thanks, glad to see the issues have been addressed. Still not really sold on using objects instead of ids though - looks like a premature optimization to me: trying to make some room for backward compatibility having clear API versioning system is not really necessary IMO. But that's just a my personal preference, I guess.