Validation of uriParameter fails when using custom type

[bennidi]

I would like to use my custom types in uriParamer parts of the resource description. It seems that the console does not handle these correctly because it shows a validation error for a valid entry. When I inline the type definition it works.

# This works

/{user}/{feature}:
  uriParameters:
    feature:
      type: string
      enum:
          - A
          - B
          - C

# Validation breaks here

types:
  Feature:
    type: string
    enum:
        - A
        - B
        - C

/{user}/{feature}:
  uriParameters:
    feature:
      type: Feature

[sichvoge]

@bennidi can you confirm that this is still happening. I tried that and I don't get any validation error.

[bennidi]

@sichvoge Yes, the problem persists with latest master. The provided example was illustrative though. My actual raml file is more complex. The main difference that I can spot is that I import the types using

type: !include ./types.raml

The console does not create a drop-down box for the enum values and whatever valid value I type in, it is rejected.

[sichvoge]

Can you create a small reproducable example?

[bennidi]

Type descriptions in extra file

UUID:
  type: string
  pattern: ^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$
  example: 82b3ac87-f9db-4ade-a374-4316c480de25


CountBasedExpiration:
  description:  |
    Counter based feature usage means that each use of a features decreases counter
  type: object
  properties:
    count:
      type: number

TimeBasedExpiration:
  description:  Shows how often a feature can still be used
  type: object
  properties:
    start:
      type: datetime
      example: 2016-02-28T16:41:41.090Z
      format: rfc3339 # the default, so no need to specify
    end:
      type: datetime
      example: 2016-02-28T16:41:41.090Z
      format: rfc3339 # the default, so no need to specify


FeatureType:
  type: string
  enum:
    - ACCESS_KISMET
    - ACCESS_MESSAGES

Feature:
  description: |
    Specifics about a particular instance of a feature (associated to a given user)
  type: object
  properties:
    name:
      type: FeatureType
    expiration:
      type: TimeBasedExpiration | CountBasedExpiration
      description: |
        Contains either a date range for the enabled period or a counter.

The main raml file

#%RAML 1.0
title: Uri Parameter test
baseUri: /

# Include all defined types
types: !include types.raml


/features:
  description: |
    Manage features on a per user basis. Allows to query or modify the status of a feature.
  /{user}/{feature}:
    uriParameters:
      user:
        type: UUID
        example: 497b14f6-eacb-4e6d-8f74-989b04b4debf
      feature:
        type: FeatureType

    get:
      description: |
        Returns a list of enabled features of the given type
      responses:
        200:
          body:
           application/json:
             type: Feature[]
             examples:
               empty: []
               countbased-feature:
                  -
                    name: ACCESS_KISMET
                    expiration:
                      count : 5
               timebased-feature:
                  -
                    name : SEND_CONTACT_MESSAGE
                    expiration:
                      start: 2016-02-28T16:41:41.090Z
                      end: 2016-02-28T16:41:41.090Z
        404:
          body:
            application/json:
              example:
                message: This feature is currently not enabled for this user

    post:
      description: |
        Enable a feature for a user
      body:
        application/json:
          type: Feature
      responses:
        200:
          body:
           application/json:
             type: Feature[]
             description: Returns a list of all active features of the given type
             examples:
               enabled-features:
                  -
                    name: ACCESS_KISMET
                    expiration:
                      count : 5

[sichvoge]

Had to change your example a little bit since there is a small bug inside your timebased-feature example. You used a name that is not defined in your enum.

After that, I see what you mean; you are basically expecting a dropdown list for the feature URI parameter with two entries: ACCESS_MESSAGES and ACCESS_KISMET. Right? That would need to be the same for headers, etc.

[sichvoge]

I also could reproduce that the validation does not work:

But the values are correct. So this is a bug.

[bennidi]

I am glad you could reproduce the issue. Showing a drop-down based on enum values makes a lot of sense to me (and it is the behavior you get when not using a type reference).

[sichvoge]

Created a separated enhancement request #412. Go ahead and vote for it by "add a reaction" with a thumbs up