Missing object definitions in reference section (version 2.1)

[jfcote87]

userSocialIdResult and newAccountDefinition have a field name "socialAccountInformation" that references "#/definitions/UserSocialAccountLogins". This object does not exist.

"newAccountDefinition": {
      "type": "object",
      "properties": {
      ...
        "socialAccountInformation": {
          "$ref": "#/definitions/UserSocialAccountLogins",
          "description": "Contains properties that map a DocuSign user to a social account (Facebook, Yahoo, etc.)"
        }
     }

"userSocialIdResult": {
      "type": "object",
      "properties": {
        "socialAccountInformation": {
          "description": "Contains properties that map a DocuSign user to a social account (Facebook, Yahoo, etc.)",
          "type": "array",
          "items": {
            "$ref": "#/definitions/UserSocialAccountLogins"
          }
        },
        "userId": {
          "description": "The ID of the user to access. Generally this is the ID of the current authenticated user, but if the authenticated user is an Administrator on the account, `userId` can represent another user whom the Administrator is accessing.\n",
          "type": "string"
        }
      },

I noticed that there is a "socialAccountInformation" object that is not referenced by any other object. Is that the correct type for the fields?

"witness" object contains the field "offlineAttributes" with a reference of "#/definitions/offlineAttributes" which does not exist.

"witness": {
      "type": "object",
      "properties": {
      ...
        "offlineAttributes": {
          "$ref": "#/definitions/offlineAttributes",
          "description": "Reserved for DocuSign use. "
        },

[LarryKlugerDS]

Thank you for the report.

Re: I noticed that there is a "socialAccountInformation" object that is not referenced by any other object. Is that the correct type for the fields?

Yes. Our Swagger toolchain should have renamed the object to UserSocialAccountLogins. I have filed DCM-3469

Re: missing the offlineAttributes object definition.

Yes, that is by design. We aren't exposing the capability to do offline signing except via the iOS SDK.

[roshanail]

Compiling the generated classes gives the following errors. I looked at the json and the corresponding definitions are missing

[ERROR] : cannot find symbol symbol: class DocusignOfflineAttributes [ERROR] cannot find symbol symbol: class DocusignSignHashDocument [ERROR] cannot find symbol symbol: class DocusignUserSocialAccountLogins

[LarryKlugerDS]

Hi @roshanail , Those object definitions are reserved for DocuSign use so we don't include them in the Swagger file.

[mrjono1]

I am also having this issue, if they are reserved for docusign there should be no reference to them in the customer facing swagger. I have had to manually edit the swagger so I can use it, and as I am not a DocuSign dev I have to make assumptions about this editing that could be incorrect.

Yes, that is by design. We aren't exposing the capability to do offline signing except via the iOS SDK.

By design? which makes the file invalid?

[InfinitySamurai]

@LarryKlugerDS Is there any additional information about this? It's reasonable that you remove certain attributes from the swagger that are not used externally, however the fact that it makes the swagger invalid makes dev life a lot harder and can lead to days of head scratching. Should the swagger additionally have references to those definitions removed so that the swagger can remain valid?

[LarryKlugerDS]

Hi, I've checked with DocuSign engineering. They say that the DocusignUserSocialAccountLogins issue is fixed in the latest Swagger file. Is it?

WRT to

• DocusignOfflineAttributes
• DocusignSignHashDocument

I will ask the Engineering group to investigate. I will also raise the general issue about providing stubs.

@InfinitySamurai -- what tool are you using that complains about the undefined objects? As you can see from the updated Readme, the Swagger people claim that the files are Swagger compliant. (I understand and agree with you that the objects or a stub should be included.)

Note that if any of those objects are included in responses then the Swagger file won't help you decode them.

[niceprogramming]

The issue still occurs for the DocusignSignHashDocument on the newest release. Path #/definitions/signHashDocument

Currently, the tooling we are using is NSwag

"completeSignHashResponse": {
      "type": "object",
      "properties": {
        "documents": {
          "description": "A complex element that contains details about the documents associated with the envelope.",
          "type": "array",
          "items": {
            "$ref": "#/definitions/signHashDocument"
          }
        },
        "redirectionUrl": {
          "description": "",
          "type": "string"
        },
        "remainingSignatureRequests": {
          "description": "For documents that require multiple signatures, this is the number of signature requests remaining.",
          "type": "string"
        }
      },
      "x-ds-definition-name": "completeSignHashResponse",
      "description": "",
      "x-ms-summary": ""
    }

[ecdpalma]

I get the same by using this tool https://github.com/ferdikoomen/openapi-typescript-codegen.

PS: Using master's (March 19th) version.

EDIT: PS added

[LarryKlugerDS]

Thank you @ecdpalma , I am escalating this issue within the engineering org.