You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When oneOf is nested within allOf, the allowed value of the schema within oneOf is not showing. The title and the description of the nested schemas are fine, just not the allowed value. When a constant value is used within the upper allOf, the allowed value is showing properly
Context
I am using nested schemas in my project, but the allowed values are not visible. The users now have to look directly into openapi.yaml to find the allowed values.
Current Behavior
Allowed values are not shown in Elements when they are part of a schema within oneOf that is nested in allOf.
See the contents of the OAS below:
openapi.yaml
openapi: 3.1.0
info:
title: Sample API
version: 0.1.9
paths:
/pets:
get:
requestBody:
content:
application/json:
schema:
oneOf:
- $ref: "#/components/schemas/Cat"
- $ref: "#/components/schemas/Dog"
discriminator:
propertyName: pet_type
components:
schemas:
Pet:
type: object
required:
- pet_type
properties:
pet_type:
type: string
discriminator:
propertyName: pet_type
Dog: # "Dog" is a value for the pet_type property (the discriminator value)
allOf: # Combines the main `Pet` schema with `Dog`-specific properties
- $ref: "#/components/schemas/Pet"
- type: object
# all other properties specific to a `Dog`
properties:
bark:
type: boolean
foo:
type: string
const: bar
breed:
type: string
# enum: [Dingo, Husky, Retriever, Shepherd]
oneOf:
- $ref: "#/components/schemas/Dingo"
- $ref: "#/components/schemas/Husky"
- $ref: "#/components/schemas/Retriever"
- $ref: "#/components/schemas/Shepherd"
Cat: # "Cat" is a value for the pet_type property (the discriminator value)
allOf: # Combines the main `Pet` schema with `Cat`-specific properties
- $ref: "#/components/schemas/Pet"
- type: object
# all other properties specific to a `Cat`
properties:
hunts:
type: boolean
age:
type: integer
Dingo:
title: Dingo
type: string
const: Dingo
description: The dingo is an ancient (basal) lineage of dog found in Australia.
Husky:
title: Husky
type: string
const: Husky
description: Husky is a general term for a dog used in the polar regions, primarily and specifically for work as sled dogs.
Retriever:
title: Retriever
type: string
const: Retriever
description: A retriever is a type of gun dog that retrieves game for a hunter.
Shepherd:
title: Shepherd
type: string
const: Shepherd
description: The German Shepherd, also known in Britain as an Alsatian, is a German breed of working dog of medium to large size.
Expected Behavior
Allowed values are visible in Elements when they are part of a schema within oneOf that is nested in allOf.
Possible Workaround/Solution
Because description is displayed properly, I use description with code markup to simulate the allowed values field. However, this is not the preferred use of the description field.
When oneOf is nested within allOf, the allowed value of the schema within oneOf is not showing. The title and the description of the nested schemas are fine, just not the allowed value. When a constant value is used within the upper allOf, the allowed value is showing properly
Context
I am using nested schemas in my project, but the allowed values are not visible. The users now have to look directly into openapi.yaml to find the allowed values.
Current Behavior
Allowed values are not shown in Elements when they are part of a schema within oneOf that is nested in allOf.
See the contents of the OAS below:
openapi.yaml
Expected Behavior
Allowed values are visible in Elements when they are part of a schema within oneOf that is nested in allOf.
Possible Workaround/Solution
Because description is displayed properly, I use description with code markup to simulate the allowed values field. However, this is not the preferred use of the description field.
Steps to Reproduce
docker compose up
.openapi.yaml
from thehtml
-folder with theDog
-schema in browser.Environment
The text was updated successfully, but these errors were encountered: