This change was long overdue, and we're glad we were able to address it! 🥳

Suppose you have ie. a model with 10 fields, 9 of which are optional. Until now, when creating a record, you were required to specify... all 10 fields. If you didn't want any value for the optional ones, you were required to pass a null value in any case, or the API call would fail:

1
const { SiteClient } = require("datocms-client");
2

3
const client = new SiteClient("YOUR-API-TOKEN");
4

5
const record = await client.items.create({
6
  itemType: "1234",
7
  requiredField: "Lorem ipsum",
8
  optionalField1: null,
9
  optionalField2: null,
10
  optionalField3: null,
11
  optionalField4: null,
12
  optionalField5: null,
13
  optionalField6: null,
14
  optionalField7: null,
15
  optionalField8: null,
16
  optionalField9: null,
17
});

In addition to being redundant and inconvenient, this was a maintainability problem over time, because when a new optional field gets added on the model, you need adapt every script and add that null value. Well, now optional fields can be omitted from the payload during creation:

const record = await client.items.create({
  itemType: "1234",
  requiredField: "Lorem ipsum",
});

Nice, simple and clean. Happy friday!

With today's update, we decided to split two permissions in order to give you a more fine grained permission system.

Before

After

What happened to existing roles in my project?

This change did not alter what your users were already able to do, or not to do. For instance, if an existing role had the ability to "Create/duplicate" records, the same role has both the permissions ("Create" and "Duplicate") defined.

You can now query the list of existing locales directly from GraphQL:

query Locales {
  _site {
    locales
  }
}

And you get back the array of the locales:

1
{
2
  "data": {
3
    "_site": {
4
      "locales": [
5
        "en",
6
        "it",
7
        "ar"
8
      ]
9
    }
10
  }
11
}

We have improved our support to RTL languages by automatically switching text fields to RTL when necessary.

This choice is made automatically depending on the language selected.

We have just added the possibility of specifying a length validation on Structured Text fields, as was already possible for string and text fields:

In more than one official communication, Microsoft has announced the end of life for Internet Explorer 11:

• On August, it removed support for IE11 for all Microsoft 356 online services;

• In May, it announced the permanent retire of IE11 as of June 2022.

Beginning October 25, 2021, DatoCMS will no longer support Internet Explorer 11 (IE11) and users may have a degraded experience, or be unable to connect to our apps and services.

If you're still using Internet Explorer, you will need to transition to Microsoft Edge (or any other modern browser) before October 25 to start enjoying a faster, more secure and more modern browsing experience.

This change will allow us to work faster, and offer better performance on the latest browsers.

You can now copy the content of a localized structured text from the main locale to the others, with just one click:

We have recently released two new options for the webhook body that we are sending out.

1. you can now pick the API version number defining the format of the payload that we are sending out

2. you can also decide if you want to have directly expanded in the record value the nested blocks that might be part of it

Have a look at the interface:

Some of the most useful and used triggers for our webhooks are those revolving around records creation/update/deletion, and when it comes to a "record update" event, it is very common the need to know exactly what has changed. So far, it was not that easy to get that information.

Well, now it is! For "record update" events, the webhook payload now presents the record data both before the update operation (previous_entity) and after (entity), making diffs extremely easy on your end.

Integrations/automations like "only do X if the title has changed" are like 1000% faster to develop:

1
{
2
  "environment": "foo-bar",
3
  "entity_type": "item",
4
  "event_type": "update",
5
  "entity": {
6
    "id": "39830648",
7
    "type": "item",
8
    "attributes": {
9
      "name": "Mark Smith",
10
    },
11
    "relationships": { ... },
12
    "meta": { ... }
13
  },
14
  "previous_entity": {
15
    "id": "39830648",
16
    "type": "item",
17
    "attributes": {
18
      "name": "John Smith",
19
    },
20
    "relationships": { ... },
21
    "meta": { ... }
22
  }
23
}

For security reasons, we have decided to remove any previously saved Netlify/Vercel token information from all existing build triggers. This change no longer allows you to view build logs directly from within the DatoCMS interface.

The reason for this change is that a project's read-only token API has read access to build triggers, but these were exposing third-party tokens that potentially allowed destructive operations to be performed. If you have publicly shared any DatoCMS key and you have build triggers pointing to Netlify/Vercel, we recommend rotating the keys of these these services.