ReadOnly object within oneof being displayed within schema for update requests

[AlaNDGT]

Version: 9.3.3

Description:

When using oneof with direct objects having readonly behaviour, it's being displayed.

But when referencing a schema with readonly object, it does not show up.

Here's a screenshot comparing both behaviour:

Additional:

Would be great if we could completely hide oneof fields which have only readonly schemas/objects?

Example OAS:

openapi: 3.1.0
info:
  title: sample
  version: '1.0'
servers:
  - url: 'http://localhost:3000'
    description: test
paths:
  /test:
    post:
      summary: Create
      operationId: post-test
      responses:
        '201':
          description: Created
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Test'
            examples: {}
        description: ''
      description: ''
    parameters: []
components:
  schemas:
    Test:
      title: ''
      type: object
      description: ''
      examples: []
      x-tags:
        - test
        - user
      properties:
        direct:
          oneOf:
            - properties:
                foo:
                  type: string
              behavior: Read Only
            - properties:
                bar:
                  type: string
              behavior: Read Only
          type: object
        reference:
          oneOf:
            - $ref: '#/components/schemas/Foo'
            - $ref: '#/components/schemas/Bar'
    Foo:
      type: object
      title: Foo
      properties:
        foo:
          type: string
      readOnly: true
    Bar:
      type: object
      title: Bar
      properties:
        bar:
          type: string
      readOnly: true

[mrin9]

can you replace behavior: Read Only -> readOnly: true in your sample spec ?

[AlaNDGT]

Ah my bad, did not noticed. Seems to be same now with readOnly: true

Is it possible to completely hide oneof which contains only read only schemas?

[mrin9]

we do an incremental construction of the schema, to achieve what you are asking will need us a big refactoring of the way these views are generated and even bigger testing effort to pass through various test cases. I do not see much of a value add for the effort needed. therefore will close this issue. However I am open to PRs if you or anyone interested like to make an effort

[mrin9]

Since we decided to include a breaking change elsewhere(d26602dff8eda329b83a9e2e39d1758b5fbaacf1) , so we might as well revisit this