Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

displayField causing validation errors when not set #53

Closed
jsdalton opened this issue Feb 20, 2015 · 1 comment · Fixed by #54
Closed

displayField causing validation errors when not set #53

jsdalton opened this issue Feb 20, 2015 · 1 comment · Fixed by #54
Assignees
Labels

Comments

@jsdalton
Copy link
Member

This related to pull request #52.

So i just upgraded to 0.6.1 and in doing so I hit a validation error in the case where a display field is not defined on a content type. Digging here's what I think might be happening:

:displayField is a string property. When I load up a content type without a displayField being set, the nil or missing value is being coerced into a blank string i.e. "". On a subsequent update to that content type, the displayField is now being explicitly passed in the request as displayField: "" (that is instead of dispalyField: null). This works, but when the content type is activated a validation error is thrown:

{
  "sys": {
    "type": "Error",
    "id": "ValidationFailed"
  },
  "message": "Validation error",
  "details": {
    "errors": [
      {
        "name": "referencesFieldId",
        "details": "Attribute displayField must reference a field's id",
        "displayFieldValue": "",
        "allowedValues": [
          "productName",
          "headling",
          "description",
          "bullets",
          "pdpSketch",
          "relatedContent",
          "lifestyleImages"
        ]
      }
    ]
  }
}

Not sure the best way to solve, but you might need to check if display_field.blank? and then explicitly set :displayField to nil if so, as opposed to letting the "" value slip through.

We're holding off on 0.6.1 in the meantime.

Many thanks!

@pxlpnk
Copy link
Contributor

pxlpnk commented Feb 20, 2015

See #54 for a fix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants