ColumnID auto-naming from title instead of column type

monday Apps & Developers Feature Requests - API and Apps Framework
, ,
1

Up until API v2023-07, I have used the column title in my queries, since they are meaningful and representative of their actual data. In API v2023-10, column titles have been relegated out and are now only available via sub-query of column { title }. (Except not really, because this exhausts the query depth: "Query has depth of 7, which exceeds max depth of 6"...)

The recommendation from support was to use columnID instead. The problem is, columnID is generated randomly when users create a column via the UI. The only way to have meaningful columnIDs is to create board columns via the API.

So instead of having readable entities in my JSON payload, to work with in our scripts, we are now stuck with ["text2", "text7", "creation_log", "item_id5", "text5", "dropdown1", "text31", "status2"] and so on.

I’m currently rebuilding this particular board using the API, column by column, in order to rework my Python scripts to accommodate using columnID instead of title. I am not sure why column titles had to disappear in this way, but in any case, we now have a really legitimate need for the ability to change column IDs… except, we all know that changing field names in the database is not going to be feasible. So,

When I create a column via API with the below mutation, I get a shiny new column titled “Invoice Number” with a lovely columnID- invoice_number:

mutation{
  create_column(board_id: 0123456789, title:"Invoice Number", column_type:text) {
    id
    title
  }
}

But I didn’t specify that column ID, it was generated based off the title! SO, my feature request is to simply have the UI work the same way. If there is already (for example) a text field on that board called “Note”, then sure, give it a columID of note1, or note2 etc. We can live with that. But otherwise, I can’t imagine it would be difficult to adjust the default columnID naming to base off of the user-supplied title, rather than a random number appended to the column type, like text31.

As it stands moving forward, here is what we are facing: users will create and setup new boards via the UI. Then they’ll come and ask for some special (API-requiring) use of that board data. At this point we will either have to

  • a) live with the meaningless IDs in our code, or

  • b) rebuild the entire column structure via API to produce meaningful column IDs that aren’t a nightmare to reference in the query payload.

I suppose option C is to build users an external tool for column creation and bypass the Monday UI altogether, but that’s of course not a direction anyone wants to go.

Thanks for considering!

2

I’m a little confused, why does the exact column ID even matter? I’ve never encountered a circumstance I need to make any logic choices based on the column ID (unless what I’m building is board specific, and not intended to be reusable or scale). If your recipe is configured with fields or mapping, then the key of the field should be the determinant factor of what to do with the column ID, not the value of the ID.

If you have a UI app then you would have a configuration step where you map columns for a purpose or such, and store that mapping in the storage.

If your app creates columns on a board for specific use, then just save the arbitrary ID in the storage (or your database) along with what role the that column serves within your application.

To me this sounds less like a monday issue and more like a lack of proper abstraction in your app. My two cents.

3

Why the extra step of mapping?

4

Mapping, or a field to select a column for an automation, etc. Otherwise everything is baked into your code, its brittle in some fashion around IDs in general.

These techniques provide some form of abstraction that can be modified without code changes - simply by editing a recipe, or adjusting something in the app UI. (again I don’t know exactly what your app does, nor the scope - so I am somewhat limited).

5

I can appreciate your view from app best practices. I’m not an app developer though, I use Monday for our business. Scripts are usually board and use-case specific. I don’t need layers of abstraction (or exhaustive error-handling, and so on)- these are superfluous and just extra work for me.

So for my usage of Monday (and possibly others like me) this change seems arbitrary on the back end and easy to make, and would make the scripts shorter and more maintainable.

6

Hello there @jsararas,

I have shared this request with the team :grin:

Cheers,
Matias

8

Much appreciated @Matias.Monday thanks!

9

Happy to help @jsararas !

10

For us the column ID matters because we use Emails & Activities app with extensive use of templates. In the templates you refer to the column IDs and this means we need an email template for each board. However, some emails that we send from different boards are the same on multiple boards, so 1 template should be enough.

I don’t develop and don’t plan too because the lack of time. I just use Monday.com to streamline our workload and contact with clients. It would be best if we just could alter the colum ID, so no matter what board, we could use the same column ID for columns with the same data.