@Pask we are glad this is working now!

Let us know if you have any other questions or issues!

Cheers,
Matias

Thanks for the updates. I posted a question here regarding what the [ID!] datatype means compared to [Int]: Is the ID! data type alphanumeric?, since many of the IDs are changing to that. Any help would be appreciated.

Hello @PluginGenie,

Your topic was replied!

Cheers,
Matias

When can version 2023-10 be used in production applications? Should we hold off on using it in production until October, when it is officially released? Could there be breaking changes in 2023-10 between now and October? Thanks for all your helpful advice!

Hey @PluginGenie – you’re right, the version will not be stable until October 1st. We’re not planning any major changes but we can’t guarantee that we won’t make small tweaks.

Here’s my 2 cents:

Strike while the iron is hot and start reviewing and migrating any affected queries. However, keep that version on a separate branch (aka not production).

Between now and October, keep an eye on the API changelog in case we make any further changes.

Let me know if that helps!

@rachelatmonday - I recognize this may be a little late to the discussion and possibly just me, but the description of the rolling window of versions ( API Versioning ) seemed more confusing than it needed to be. I drew it out this way to help me better mentally capture the flow. Am I on target here?:
(NOTE: Not sure whether there will be a standing pattern of what the Default version as of 4/1/2024 - or whether each API Changelog and Release Notes will have to be watched)

Hi @marksmalley,

Thanks for the feedback! I would definitely agree with you. We’ve been adjusting that article to make it more clear but also understand that there’s a lot of information that can make it confusing. That said, your diagram is spot on!

Since this is our first version that contains so many breaking changes, we are providing devs extra time to migrate to the new version. Therefore, the default version if you send a request without a header will remain 2023-07 until January 1st, 2024.

After January 1st, we will resume the normal pattern of the most recent stable version being the default. That means 2024-01 will be the default starting January 1st, 2024, 2024-04 on April 1st, 2024, 2024-07 on July 1st, 2024 and so on 😃

Please let us know if you have any other questions!

Best,
Rachel

The is helpful clarification, @rachelatmonday . Thank you. I’ve included the clarification here for completelness:

Perfect, that looks amazing! Thanks for sharing here as well - I am sure others would love to see it instead of just reading it 🙌

Hi, I have a question regarding the date field. You can find more information about it in this post:

Any help would be appreciated. Thanks!

Hello there @yarhuoy!

Your question will be replied in that other topic 😁

Hey friends! I collected all our API migration resources so far in one post. Check it out below!

Hello @rachelatmonday and @dipro !

Per Breaking change: `Text` field empty value for mirror, dependency, and connect boards columns my understanding is that the column_values will return empty results for a connect_boards column. However, I am testing 2023-10 and successfully return text for my connect_boards (even connections with multiple items):

{
boards(ids: 3390430078) {
items_page(limit: 25, cursor: null) {
cursor
items {
name
column_values {
column {
title
id
type
}
id
text
}
}
}
}
}

This is GREAT news - but it seems to be contrary to what the article is saying? Could it be that the connect_boards column will actually return text representation of the items (items’ names) that they are linked to?

I don’t want to depend on it if it will be ripped out later.

Thanks!

Hey Mark, will need to double check this with our R&D team and get back to you! Some folks are out of office so I might only get a response next week at some point.

No problem! Thanks, @dipro

Hey Mark, there’s a bug – the generic column_values object should return null values but is returning data at the moment. We’ll fix it soon.

You will need to use the BoardRelationValue fragment to get this data instead. Something like this:

{
  boards(ids: 4580008782) {
    items_page(limit: 25, cursor: null) {
      cursor
      items {
        name
        column_values {
          column {
            title
            id
            type
          }
          id
          text
          ...on BoardRelationValue {
            id
            text
          }
        }
      }
    }
  }
}

The reason behind this is that retrieving connected data is resource-intensive, so we only want to do it when the client explicitly asks for it (using this BoardRelationValue type).

NB: the migration guide originally mistakenly said you need to use the linked_items field to do this; you can actually just use the fragment above.

Thanks, @Dipro :-). Figured that might be the case but thought worth a quick confirmation.

Update – we just postponed the release of 2023-10 to Jan 15th. More info here: Postponed version release

Hey @Dipro - I implemented the BoardRelationValue fragment as suggested (see below) against ‘2023-10’ in the API Playground. The result ends up being exactly as it was as if the connect_board column brought back the crossboard selections in the ‘text’ field without the fragment (like other type fields).

Is this how it will return results (and the fragment is doing its magic)? Or is the board fragment not yet working for that type of column. In other words, am I going to need to keep my eye on the fact that an implementation will bring things back differently (and break what the fragment currently shows)?

Thanks in advance 🙂 !

-Mark

{
boards(ids: 3390430078) {
items_page(limit: 25, cursor: null) {
cursor
items {
name
column_values {
column {
title
id
type
}
id
text
…on BoardRelationValue {
id
text
}
}
}
}
}
}

Hey @marksmalley – this is a bug with our query layer that is going to be fixed soon.

The fragment works as expected right now (aka the query above is correct & will continue to work).

The bug is that when you don’t use the fragment, the connected data is (erroneously) returned – when it should be blank.

Yeah - I guess (ignorance on my part with graphql fragments), I was surprised that the modified query allowed the same resulting effect (which is great). Correct me if that is not the case.

Thanks for the quick response, @dipro !

You’re exactly right. When you use the fragment the returned data is nested in the same way as if you omitted the fragment. Which is an AMAZING feature of GraphQL. 🔮

A post was split to a new topic: Is monday.com a spec-compliant GraphQL implementation?

@marksmalley – just a heads up, we adjusted how you can return a stringified column value from a “connected” column.

As planned, the text field will still return blank for all connected column values (Connect Boards, Mirror and Dependency).

But how to access this data has changed. Instead of using the text field, you need to now use the display_text field in a fragment:

query {  
  items (ids:[1234567890, 9876543210]) {  
    column_values {  
      ... on MirrorValue {  
        display_value  
      }  
    }  
  }  
}

More details and explanation here: Updates to MirrorValue, DependencyValue, and BoardRelationValue column values

Thanks, @dipro for the proactive update! While not as seemless as the other, I get that there are probably reasons you need the API to always return null (not violate that via a fragment implementation) for those types of fields and have the values returned via an alternative field. I appreciate you sharing this so I can start working on the implementation. Much appreciated!