Hi, we try to make our requests smaller, and we try to use the nested parameter action_memberCreator=false when querying for task + nested actions, but it’s not applied.
as described here:
We are able to get smaller results, with the action_memberCreator_fields=id param.
But, I suppose this add more charge on your server, than using action_memberCreator=false.
What am I doing wrong?
I’ve just tested what you described and got the same result; the action_memberCreator parameter only accepts a value of true, and the false value has no effect if you put actions=all in the request.
In the documentation, it does say that the parameter only supports a single value ‘Bool’, not ‘true, false’ like the other boolean parameters, so perhaps that’s a statement of fact on the matter?
Personally speaking, given that only one member can ever be a card’s creator, it’s not exactly going to be a large dataset returned for that action, so I’d suggest that the presence of the superfluous memberCreated action in the response isn’t worth the effort of trying to find a way to exclude it from the response; it’s easier to just ignore it when parsing the response via your code.
We looked at it because, in some cases for very specific tasks, we can have lot of actions, more than ususal.
And, in these cases, getting the cards, can take, from an average of 50-150ms up to 5000-10000 ms.
We had a sample where getting 10 cards (using batch endpoint) returned a total of 2200 actions!
Just to serialize-deserialize the json string, lot of time is consumed.
I am able to reduce the response size by 25-35% just by adding "action_memberCreator_fields=id, that is great.
But, if I can totally remove it, I am almost sure that, on Trello side, that will reduce the complexity of the query, because we already a field named “idMemberCreator” in every action, so we don’t need the user object in the response.
And, specifying “all” or any other value in the “actions” parameter doesn’t change the presence of “memberCreator” in the response.
As you said, because the documentation indications “Bool” as a valid value, there’s something strange here that should be fixed!
Fair enough. You make a good argument on your requirement due to the compound effect of the small increase in the JSON response size.
Oh, definitely. I have personally made a comment on that documentation page that there’s something fishy with that section that needs to be remediated.
If you want to pursue this whole topic further, I suggest you raise a support case with Atlassian and see where it takes you, unless a Trello dev team member is watching this thread and is going to actively response to it.