Sign Up ›
  • Brandon White
  • NEWBIE
  • 0 Points
  • Member since 2016
  • Tasktop
  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 3
    Questions
  • 2
    Replies
2 replies

Max length applied to Rich Text Fields

I recently encountered an error (400 error code: STRING_TOO_LONG) when attempting to update a rich text field through the REST API. I was passing some markup to this field that included a literal '&' ampersand character, which is encoded in HTML as '&'. In my case, the field had a maxlength limit of 256 characters (the lowest threshold you can place on a rich text field at the moment).

I thought that the literal '&' character would only count as 1 character against the maxlength limit but it seems that Salesforce considers this '&' character to count as 5 characters in its encoded representation. This is similar for other types of encoded characters such as copyright ('&copy'). If the '&' counts as 5 characters against the limit, then I can understand why I received the STRING_TOO_LONG error.

I did check and this behavior is consistent in the Salesforce Web UI.

I don't think this behavior is necessarily intuitive, particularly if you're not sure how certain characters are encoded behind the scenes. If you're working with a rich text field that has a max length of 256 characters, it's easy to craft some text that, at least visually, looks to be under the max length limit. But in practice, because the max length is applied against the encoded characters, the total length of the text exceeds the max length limit.
0 replies

Obtain the complete list of Picklist values via REST API (both active and inactive)

Is there a way of listing ALL the picklist values, both active or inactive via the REST APIs?

For example, we can obtain an incomplete list of picklist values for the Case object via: 
/services/data/v38.0/sobjects/Case/describe
or alternatively for a specific field Case Type 
/services/data/v38.0/tooling/query/?q=SELECT Metadata FROM FieldDefinition WHERE EntityDefinition.QualifiedApiName = 'Case' AND FieldDefinition.QualifiedApiName = 'Type'

However, with both lists, on can observe that active or isActive have the value of true, and no 'inactive' values are returned.
Yet through the Case configuration interface (or any picklist configuration interface), the set of possible values that are active are shown with a table of inactive values below.

This behaviour is slightly problematic, as non-restricted picklists can be set to any value that is not in the active picklist values, however, the new value is by default inactive.


If there is no way of retrieving both active and inactive values, is there perhaps an easy way to mark a value as active via the REST API?
2 replies

Case Status is nillable but cannot be set to null through REST API?

We have noticed some strange behavior when trying to manipulate the Status field through the Force.com REST API. Take cases as an example:

When we fetch the field metadata (/services/data/v37.0/sobjects/Case/describe), we can see that the Status field is nillable:

{
      "name": "Status",
      "nillable": true,
... // other properties omitted for brevity
}

We have attempted to update an associating Case instance and set the value of this field to null like so:

PATCH /services/data/v37.0/sobjects/Case/<id>
Payload:
{
    "Status": null
}

We get a 204 error code suggesting the request was successful. But when we fetch the associating Case, the Status field retains the picklist value it had immediately before the PATCH request.

This behavior is different from any other standard or custom picklist that we have defined on our Case objects:
  • If a picklist field has nillable = false, then we get a 400 error response when we attempt to set the value to null. That matches our expectations because this field requires a non-null value.
  • If any other picklist field has nillable = true, then we can set the picklist field to a null value. A subsequent fetch of that Case shows that the picklist field value is indeed null.
Given the behavior of the Status field today, it seems like it would be more appropriate for the Status field metadata to specify nillable = false instead of true to reflect the fact that it seems to require a non-null field value. Ideally the server would also return an error if a client attempts to set it to null.
2 replies

Max length applied to Rich Text Fields

I recently encountered an error (400 error code: STRING_TOO_LONG) when attempting to update a rich text field through the REST API. I was passing some markup to this field that included a literal '&' ampersand character, which is encoded in HTML as '&amp;'. In my case, the field had a maxlength limit of 256 characters (the lowest threshold you can place on a rich text field at the moment).

I thought that the literal '&' character would only count as 1 character against the maxlength limit but it seems that Salesforce considers this '&' character to count as 5 characters in its encoded representation. This is similar for other types of encoded characters such as copyright ('&copy'). If the '&' counts as 5 characters against the limit, then I can understand why I received the STRING_TOO_LONG error.

I did check and this behavior is consistent in the Salesforce Web UI.

I don't think this behavior is necessarily intuitive, particularly if you're not sure how certain characters are encoded behind the scenes. If you're working with a rich text field that has a max length of 256 characters, it's easy to craft some text that, at least visually, looks to be under the max length limit. But in practice, because the max length is applied against the encoded characters, the total length of the text exceeds the max length limit.
2 replies

Case Status is nillable but cannot be set to null through REST API?

We have noticed some strange behavior when trying to manipulate the Status field through the Force.com REST API. Take cases as an example:

When we fetch the field metadata (/services/data/v37.0/sobjects/Case/describe), we can see that the Status field is nillable:

{
      "name": "Status",
      "nillable": true,
... // other properties omitted for brevity
}

We have attempted to update an associating Case instance and set the value of this field to null like so:

PATCH /services/data/v37.0/sobjects/Case/<id>
Payload:
{
    "Status": null
}

We get a 204 error code suggesting the request was successful. But when we fetch the associating Case, the Status field retains the picklist value it had immediately before the PATCH request.

This behavior is different from any other standard or custom picklist that we have defined on our Case objects:
  • If a picklist field has nillable = false, then we get a 400 error response when we attempt to set the value to null. That matches our expectations because this field requires a non-null value.
  • If any other picklist field has nillable = true, then we can set the picklist field to a null value. A subsequent fetch of that Case shows that the picklist field value is indeed null.
Given the behavior of the Status field today, it seems like it would be more appropriate for the Status field metadata to specify nillable = false instead of true to reflect the fact that it seems to require a non-null field value. Ideally the server would also return an error if a client attempts to set it to null.