Custom fields in the API broken

Trello
1

I have several Manatee.Trello clients who have recently been broken without any changes on their end. They did note, however, that when they disabled the Custom Fields power up, it started working again.

The error that the API is returning is “invalid value for plugins.” I don’t have any request information, but as I mentioned, it was working up to a few days ago.

Has anything changed in regard to power ups or custom fields in the API?

One user noted that it started working for them when they disabled requesting plugin data. Maybe something changed around this parameter?

2

I don’t believe that we’ve recently shipped any changes related to plugins nor Custom Fields.

Digging through our codebase, I can’t find that error message invalid value for plugins. Does Manatee.Trello do any capturing of errors that would generate that error message?

3

This is not coming from my code. I’m receiving it as a response from the API.

plugins may be a query parameter on a call. When requesting a board, I use this with a value of true.

My call as captured by Fiddler:

GET https://trello.com/1/boards/5d8bdc3bd4a86e38f3bd8b6d?fields=name%2Cdesc%2Cclosed%2Cpinned%2Cstarred%2Cprefs%2Curl%2Csubscribed%2CdateLastActivity%2CdateLastView%2CshortLink%2CshortUrl&actions=all&actions_format=list&customFields=true&labels=all&label_fields=color%2Cname&lists=open&list_fields=name%2Cclosed%2Cpos%2Csubscribed&memberships=all&memberships_member=true&membership_member_fields=bio%2Cconfirmed%2Cemail%2CfullName%2Cinitials%2CloginTypes%2CmemberType%2ConeTimeMessagesReceived%2Cprefs%2Cstatus%2Ctrophies%2Curl%2Cusername%2CavatarUrl&plugins=true&pluginData=true&organization=true&organization_fields=desc%2CdisplayName%2ClogoHash%2Cname%2Cprefs%2Curl%2Cwebsite&key=[key]&token=[token] HTTP/1.1
Host: trello.com
Cookie: dsc=f410eae8ff68cd882a33937878b05fe03a0527c976e5451172a797d2eac6233f


HTTP/1.1 400 Bad Request
X-DNS-Prefetch-Control: off
X-Frame-Options: DENY
Strict-Transport-Security: max-age=15552000
X-Download-Options: noopen
Surrogate-Control: no-store
Cache-Control: max-age=0, must-revalidate, no-cache, no-store
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
X-XSS-Protection: 1; mode=block
X-Trello-Version: 1.1805.0
X-Trello-Environment: Production
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, PUT, POST, DELETE
Access-Control-Allow-Headers: Authorization, Accept, Content-Type
Access-Control-Expose-Headers: x-rate-limit-api-key-interval-ms, x-rate-limit-api-key-max, x-rate-limit-api-key-remaining, x-rate-limit-api-token-interval-ms, x-rate-limit-api-token-max, x-rate-limit-api-token-remaining
Content-Type: text/plain; charset=utf-8
Content-Length: 25
ETag: W/"19-+kTjIWPaZz+dWnaY5Cy2NvpT2c4"
Date: Wed, 25 Sep 2019 21:29:32 GMT
Connection: keep-alive

invalid value for plugins
4

It looks like we shipped a change where we started enforcing a validator on that parameter. The valid values are: none, enabled, available, all.

What I’ve not figured out yet is why this was previously working because that validator is very old.

Would that call actually include the plugins? I would expect us to have not been returning any sort of plugins. Or, if they were being returned, I think it was the default. But I wouldn’t expect the query parameter to have had any impact on whether they were there or not.

5

Yeah, that’ll break things. I’m pretty sure that it was a boolean value when I started including the parameter. It must’ve changed at some point.

6

I was able to get a version of the server running locally for the commit prior to the one that introduced the validation checking and I confirmed that a call to /1/boards/{idBoard}/?plugins=true did not return any plugin information. However, it did return a 200 because we ignore unknown query params and values.

On the upside, you can now get plugins as a nested resource via query params and we’ll actually return the filtered plugins you ask for.