cli-microsoft365: `listitem ` commands do not handle errors that are returned by POST's to the REST API

When adding a new listitem or updating an existing one, it is possible to update DateTime fields.

However: it’s not clear what the format is for this. using the standard ISO format (yyyy-MM-ddTHH:mm:ssZ) does not work, on listitem add it throws the following error:

Error: Het item bestaat niet. Mogelijk is het door een andere gebruiker verwijderd.

Which occurs because the CLI tries to call the following URL with an actual 0 value: https://contoso.sharepoint.com/sites/sales/_api/web/lists(guid'<someguid>')/items(0)

On listitem set it simply does not do anything. But when using the --debug on update and scrolling through the logs, you can find the following:

"data": {
    "value": [
      {
        "ErrorCode": -2146232832,
        "ErrorMessage": "Voer een datum en tijd in als volgt: 23-2-2012 14:25",
        "FieldName": "SomeDateTimeFieldInternalName",
        "FieldValue": "2023-01-18",
        "HasException": true,
        "ItemId": 3
      }
    ]
  }

(Voer een datum en tijd in als volgt = Enter a date and time as follows)

So when executing a listitem add or listitem set with this new information, formatting the date like this: 23-2-2012 14:25 / d-M-yyyy HH:mm it works as expected.

Problem & Solution

The problem is that the responses of the AddValidateUpdateItemUsingPath and ValidateUpdateListItem requests are not evaluated properly. If errors are given in the request calls, the command should throw them and show them to the user.

Also there is a date format that will work in all scenario’s: yyyy-HH-mm HH:mm:ss. We should update the documentation and explain how to use datetime fields. (Either in the site locale or this specific format.) We should also explain that the timezone of the site will be used.

To fix this

spo listitem add : The errors given by SharePoint in the AddValidateUpdateItemUsingPath request should be returned to the user.
spo listitem set : The errors given by SharePoint in the ValidateUpdateListItem request should be returned to the user.
spo listitem batch add : The errors given by SharePoint in the AddValidateUpdateItemUsingPath batch-request should be returned to the user. The batching should be broken off when an error occurs. (failfast)
The documentation of the commands should explain to use the date time format of the site locale or yyyy-HH-mm HH:mm:ss.

About this issue

Original URL
State: closed
Created a year ago
Comments: 16 (16 by maintainers)

Commits related to this issue

Fix 'listitem <verb>' commands to handle errors that are returned when updating fields. Closes #4375 — committed to martinlingstuyl/cli-microsoft365 by martinlingstuyl a year ago
Fix 'listitem <verb>' commands to handle errors that are returned when updating fields. Closes #4375 — committed to martinlingstuyl/cli-microsoft365 by martinlingstuyl a year ago
Fix 'listitem <verb>' commands to handle errors that are returned when updating fields. Closes #4375 — committed to martinlingstuyl/cli-microsoft365 by martinlingstuyl a year ago

Most upvoted comments

Got it, so it’s not that it’s not working but it’s unclear which date format to use. I suggest we investigate this across sites with different locales. If the conclusion is, that the provided date must be in the format corresponding to the locale we should add that to our docs. Additionally, we could see if there’s a way for us to accept input date as ISO (so users can specify either an ISO or a locale-based date) and then convert it ourselves to the right locale just to make it easier for users.

waldekmastykarz on Jan 20, 2023

Just verified: When querying this endpoint using an ISO formatted UTC datetime value, we get a nice formatted local time returned:

But still, say we check whether an option contains an ISO formatted datetime, we cannot be sure that the target field is actually a date time field. It could be just a text field, and the user wants to write the literal ISO value to that field.

So we cannot just implement this request on ISO formatted option values.

We could of course add functionality to the CLI to allow users to help the cli to force the target value, something like: “datetime:2023-03-01T10:00:00Z” for datetimes, but I doubt whether that is a good route.

Let’s stick to the current route for now and only allow the locale-format and default format.

What do you say @waldekmastykarz?

martinlingstuyl on Mar 6, 2023

What would also make it easy, is that it offers a consistent experience. If a user may see different error messages on different calls because he happens to be talking to sites of different locales, that is a less clear experience according to me.

I guess it’s all relative: for one, I don’t know if it’s typical to have sites in different locales in one tenant. Would users be surprised that suddenly there’s a site using a different locale or would different locales belong to a separate part of the tenant and the locale’s boundaries are clear.

As long as we’re predictable and communicate clearly, we can go either way.

waldekmastykarz on Mar 4, 2023

By the way, I remember the last time I worked with DateTime and SharePoint, I had to use a SharePoint api endpoint to reliably convert from the localTime of a site to utc.

Something like this: _api/web/RegionalSettings/TimeZone/localTimeToUTC(@date)?@date=

There’s also a function that does it the other way around: UTCToLocalTime

So it converts any utc datetime to a local time in the zone of the site. That would make it easier: just use SharePoint and keep JS out of it.

martinlingstuyl on Mar 3, 2023

OK @waldekmastykarz, research confirmed that you need to use the locale of the site you’re connecting to…

I’m for treating this as a bug. The --debug option reveals that the command is actually retrieving an error message under water. We should return those errors to the user:

field values returned:
[
  {
    ErrorCode: 0,
    ErrorMessage: null,
    FieldName: 'Title',
    FieldValue: 'test123',
    HasException: false,
    ItemId: 0
  },
  {
    ErrorCode: -2146232832,
    ErrorMessage: 'Enter a date and time like this: 2/23/2012 2:25 PM',
    FieldName: 'TestDate',
    FieldValue: '15-12-2023',
    HasException: true,
    ItemId: 0
  },
  {
    ErrorCode: 0,
    ErrorMessage: null,
    FieldName: 'Id',
    FieldValue: '0',
    HasException: false,
    ItemId: 0
  }
]

Checking out out if we can use ISO dates as well might be a separate issue.

martinlingstuyl on Feb 23, 2023

Good point @waldekmastykarz! This calls for some research! DateTime fields are annoying 😀

martinlingstuyl on Jan 19, 2023

If we do that, that would be a breaking change tho.

milanholemans on Jan 18, 2023

Convert from yyyy-MM-ddTHH:mm:ssZ to d-M-yyyy HH:mm you mean? That could indeed be something we could add as well, to make the commands easier to use.

martinlingstuyl on Jan 18, 2023