Rename and enumerate Project#projectType


Ambiguous with Project#type. Alternatives to discuss: specification, schema, language. Valid values should also be enumerated in the OpenAPI spec.


Ivan Gomes
April 9, 2020, 4:22 PM

Rationale for priority is that it causes backwards incompatible changes to generated clients as used by MDKs.

Doris Lam
April 13, 2020, 10:01 PM

we can rename it to something else, but i don’t think it should be an enum - that means a generated client will need to be updated if new types are supported or a client won’t have the right “enums” for different builds of mms - it’ll be better if a description just explains what’s expected here with some examples

Ivan Gomes
April 15, 2020, 8:57 PM

I understand the difficulty of exhaustively enumerating the values if types can be added dynamically by modules. However, we need to provide consumers a way to discover all allowed values without hardcoding it client-side n times. Alternatively we can add an endpoint that enumerates supported types at runtime, which can be used to provide users with the available options when they try to create a project.


Doris Lam
April 16, 2020, 5:58 PM

i think the endpoint idea would be best, we can add something that each module can ‘register’ itself with, prob just a list of string, or maybe a map of option and description

Doris Lam
April 21, 2020, 7:25 PM

added a /schemas endpoint that gives back a list of options


Doris Lam


Ivan Gomes



Epic Link