i’m sorry to hear you are having issues with this mutation. I’ve just tried running one on my end, and was able to add a subscriber to a board within my account. Could you clarify if you are sending your user IDs as an array, i.e. [12345,678912,91266]?
Also, is the board within a Main Workspace or a Closed one?
I would also recommend removing quotes around owner, as this is a boolean and not a string value. That might help here!
Got it, I’m glad you were able to tackle the adding subscribers mutation!
I think the same issue is occurring here, as duplication type is also a boolean, and not a String, so sending it within quotes will not work. Could you try out that approach and let us know if it works?
I’d love to understand how we could make the documentation better in that sense. Could you please shed more light on how we could improve that part of our docs? I’d love to get any kind of documentation improvements added
@AlexSavchuk - I would be interested in getting on a call with you to talk about where I’m not making the connection between the documentation and the code.
Sorry, that’s an inaccuracy on my part. It is an enumerated type instead, and after testing this further, you should indeed pass it within quotes when sending it as a variable. Here’s a StackOverflow thread I’ve found with other GraphQL examlpes:
In the future, it would really help us troubleshoot and understand how we can best assist with the issues you have using our API/Apps Framework if you could provide the exact errors you are seeing using the code you’ve provided. Those errors can be quite helpful to narrow down the root cause.
@AlexSavchuk - I’m still not having any success using the code sample you gave me. I’m guessing that something isn’t translating between the vanilla javascript and the Monday SDK.
You have an extra right curly bracket, but either way, simply requesting id after a duplicate_board request will not work either, I’m afraid. it will always need to be { board { id }}.
In the second case, when you are sending your variables, they all arrive as “null” values to our API. Perhaps this is something to do with the way you are getting the values from a previous step in your code, or this might be related to the way those are JSON stringified:
The query seems to be formatted correctly in the API playground, and with providing exact values as variables, it does seem to work. Now, we just need to figure out how those variables should be passed to the SDK.
If you’re open to that, it would help us identify the issue if you share more of your code with us, as it seems like it’s not an API formatting issue, but might be related to the way those values are passed to the query.
@AlexSavchuk - The extra curly brace is because I just copied too much of the code.
When I console log all of the variables before the api call they all log valid values…
So in this case, we’d needed to make sure that we’re not sending suptTemplateVars, but instead, we’re sending a variables object. As soon as we’d made the adjustment, the values were recognized correctly.
Instead of sending: monday.api(mutateTemplate, {suptTemplateVars})
We needed to send: Monday.api(mutateTemplate, {variables})
Thank you for being available to review together, @ShawnBaden