subTypes not displayed in model

[rpofuk]

Hi!

I have service and model definition:
SERVICE:

"path" : "/process/start",
    "operations" : [ {
      "method" : "POST",
      "nickname" : "startProcess",
      "type" : "void",
      "parameters" : [ {
        "type" : "array",
        "items" : {
          "$ref" : "ProcessTaskDTO"
        },
        "paramType" : "body",
        "name" : "tasks",
        "required" : true
      }, {
        "type" : "string",
        "paramType" : "query",
        "name" : "token"
      } ],
      "consumes" : [ "application/json" ],
      "produces" : [ "application/json" ]
    } ]

MODEL:

"ProcessTaskDTO" : {
      "id" : "ProcessTaskDTO",
      "properties" : {
        "id" : {
          "type" : "string"
        },
        "type" : {
          "type" : "string"
        },
        "name" : {
          "type" : "string"
        }
      }, 
      "subTypes" : ["ProcessTaskDTO1", "ProcessTaskDTO2"],
      "discriminator": "type"
    },
    "ProcessTaskDTO1" : {
      "id" : "ProcessTaskDTO1",
      "properties" : {
        "name1" : {
          "type" : "string"
        }
      }
    },
    "ProcessTaskDTO2" : {
      "id" : "ProcessTaskDTO2",
      "properties" : {
        "name2" : {
          "type" : "string"
        }
      }
    },

But model is not displayed in UI:

Found issue #300 that's closed and it's related to response class. Is request model still an issue?

[webron]

You're using an old version of the Swagger specification and some the conversion to 2.0 may not work properly. You can try the v2.0.24 tag which may have better results, but IIRC, there was never really support for sub types in older versions.

[rpofuk]

I'm compiled latest version from master.
Is the problem in specification file (json file i supply to swagger) or the swaggerui version?

[rpofuk]

I tried with v2.0.24 and 1.2 specification but still didn't work so i tried converting.

I converted my code to new spec version (2.0) and 2.1.1 version but still getting model withouth inherited entitys:

"ProcessTaskDTO": {
      "properties": {
        "id": {
          "type": "string"
        },
        "name": {
          "type": "string"
        },
        "type": {
          "type": "string"
        }
      },
      "discriminator": "type",
      "required": [
        "type"
      ]
    },
    "ProcessFreeElementTask": {
      "allOf": [
        {
          "$ref": "#/definitions/ProcessTaskDTO"
        },
        {
          "properties": {
            "elementName": {
              "type": "string"
            }
          }
        }
      ]
    },
    "ProcessReferecedElementTaskDTO": {
      "allOf": [
        {
          "$ref": "#/definitions/ProcessTaskDTO"
        },
        {
          "properties": {
            "referecedElementId": {
              "type": "string"
            }
          }
        }
      ]
    },

[webron]

The support for allOf is currently incomplete. If you search the repository, you'll find the relevant issues.

[devigned]

Duplicate of #723

[fehguy]

@pofuk what you're seeing actually is what I would expect. Since you're missing a bit of information I'm making one assumption.

In your input, you're using the ProcessTaskDTO as the input. In your 2.0 spec version, there are only 3 fields, all of which you're seeing in the UI. Likewise for the output, I'm guessing that's the output model that you have.

If you changed the input model to, say ProcessReferecedElementTaskDTO you would have the additional field referecedElementId.

That said, what are you expecting? Or did I get it wrong regarding the input type?

[mgttlinger]

As I understand the spec if you specify a discriminator your types get treated as a polymorphic hierarchy and therefore the subtypes ProcessFreeElementTask and ProcessReferecedElementTaskDTO should be possible values and therefore shown.

This is already implemented in the develop_2.0 branch of swagger-js but not included in the current build of swagger-ui as it uses the master branch of swagger-js.

[AlbertoLeon]

I need it subTypes and allowOf in my swagger-editor
Any plans to release it?

[mgttlinger]

@AlbertoLeon It seems as though the feature was lost (or intentionally left out) when switching the branching model because it was implemented in the dev-branch but does not seem to have been merged to the master branch. I asked about this on the google group but unfortunately got no answer.

[ikitommi]

Hi. Any news on this? Haven't seen any working examples of use of discriminator with the swagger-ui.

[DerManoMann]

👍
I'd also be interested to see an update on this - I've spend a fair number of hours trying to figure out how to get the UI to do this and there are lots of contradictionary information out there.

[greggvarona]

Was anyone able to test develop_2.0 as @mgttlinger has stated?

[mgttlinger]

@geggvarona I use a custom built version of that branch when it was still around. The implementation displayed the type of the superclass as the merged properties of the subclasses (all optional)

[dklotz]

@webron @fehguy any plans for this? It would be nice if for polymorphic input parameters, the ui could give some indication of "If you set the discriminator property to 'TYPE_A', you can use the additional fields 'X' and 'Y' and if you set it to 'TYPE_B' you can use the additional field 'Z'".

[fehguy]

allOf is certainly supported. Given that this issue is over a year old, and covers many topics, I suggest opening a new one to cover anything that is in the spec but not supported by swagger-ui.

subTypes is not a supported construct in the spec, but allOf is, as is discriminator.

[zhimoda]

In my project I tried version 2.2.5 of swagger-ui. As I see it this issue is still present and relevant. If you reference a super type that uses the discriminator, swagger ui will not tell the viewer anything about the possible sub types. Without consulting the the swagger document itself the viewer sees an incomplete documentation. The choices in a project then are: not use discriminator or not not use swagger ui. If the feature was present in a branch that merged into master, what happened to it? Maybe the feature can be included without much work if it wasn't removed on purpose. I could try to look for it myself. I'm not the most qualified person to do so though. I will when I find the spare time. Anybody more qualified looking for a potential quick win?

[tanguyantoine]

Same for me. Subtypes or not shown.

[chriswebster]

I see the same issue with swagger-ui 2.2.6, I only see the definitions from the $ref in allOf

[VIIgit]

Are there any plan's timeline to support this feature also in swagger ui?

[adeshf]

@zhimoda do you have an example of a project that doesn't use a discriminator that renders properly with the swagger-ui? I'm having trouble getting subtypes working without discriminators in the swagger-ui as well.

[agiannone]

+1 polymorphism is fairly important to show otherwise it's effectively incomplete documentation

[QuasiSoDo]

currently facing the same issue

[antoinebaudoux]

currently facing the same issue

[mthippeswamy]

The issue is still exist in the newer version 3.0.2

[dlowndes]

I cannot create accurate API documentation without this feature!

[humblevladimirthegreat]

I am attempting to use the discriminator and allOf features for polymorphism. The response model does not show the subtypes, and in the models you can see the subtypes but they all have the same name as the supertype (and doesn't display the description I've set for the the subtype so the user has no way of knowing which subtype it is). You can see this happen with the example from the spec and in this issue #2438

As others have stated, this is a very important issue that I hope gets resolved. It still exists as of the docker-pulled version from yesterday, May 18th (presumably 3.0.10). NOTE: Trying it in SwaggerHug does display the names of the subtype correctly, however the description in each subtype still doesn't show (even if there is no description defined in the supertype), and no mention of subtypes in responses.

[webron]

To set everyone's expectations - we're currently not actively working on resolving this one. We're focused on adding support for the next version of the spec where additional JSON Schema constructs are added (anyOf, oneOf, not). We're hoping to resolve such rendering issues in that cycle, however, it won't be simple.

[zainkhalid]

Hi folks,

I'm running into the same issue, and am thinking of implementing a fix for my needs. Based on the last comment on this thread, I understand you all aren't prioritizing fixing this currently, but would you be able to review and merge a PR if I submit one? If so, do you have any suggestions on the best approach to implement a fix?

I'm not too familiar with the codebase, but my current thinking is something along the lines of:

1. Use the $$ref and discriminator fields to detect subtypes.
2. In the ParameterRow and Response components, detect when a model has subtypes, and:
   a. Create a ModelExamplecomponent for each subtype
   b. Create a tab for each of the ModelExample instances. The UI will have a tab for each subtype, with additional tabs under those to view the model and example value (similar to how they currently work) for the selected subtype.

The one thing I'm not sure of how to handle is that, from what I understand of the code, it seems like parameters are currently assumed to have a single schema and a singlevalue (and/or value_xml). For a polymorphic parameter, I believe this won't work because I want to display the model/schema and example value for each subtype. Is the right way to handle this to convert these fields into collections? If so, where is the right place to make that change and populate these fields for each subtype?

[webron]

@zainkhalid yeah, adding support to it is not going to be easy (yet not impossible). It might be easier to do with OAS3 support.

@shockey might be able to give you some pointers.

[zainkhalid]

@zainkhalid yeah, adding support to it is not going to be easy (yet not impossible). It might be easier to do with OAS3 support.

Yup, that makes sense, but I've got a short timeframe + pre-existing codebases to contend with, which is why I'm trying to see if I can get it to work with the 2.0 spec.

@shockey might be able to give you some pointers.

That would be great!

[raderio]

Some news about when it will be implemented?

[zybreak]

Its been 6 years, kids born when this issue was first raised are soon old enough to fix it themselves.

[webron]

So said kids would be able to fix it themselves but you can't? 😉

[zybreak]

So said kids would be able to fix it themselves but you can't? 😉

I think there’s more truth to that than I want to recognise

[ponelat]

I'm no six year old :D, but I can consolidate this issue with #2438. Closing in favour of that one.
Pull requests and thoughts on UI are still welcome!