Help

This Product Ideas board is currently undergoing updates, but please continue to submit your ideas.

BUG: Rich Text Comparisons

cancel
Showing results for 
Search instead for 
Did you mean: 
openside
10 - Mercury
10 - Mercury

There are discrepencies with Rich Text content causing issues.

If I copy/paste a rich text field into another rich text field, then create a formula that checks to see if they are equal: IF({Rich Field 1} = {Rich Field 2}, "SAME", "NOT SAME"), then it shows these as being equal.

But if I take the content from {Rich Field 1} via the API, and perform an update via API to {Rich Field 2}, the formula comparison says they are NOT SAME. Even though if I compare them from the API they have the exact same values.

So something not working when pushing via API to reflect same underlying content.

3 Comments
Bill_French
17 - Neptune
17 - Neptune

Hunch - any API process is likely involved in escaping/unescaping when reading and writing text, and especially the case with formatting markers for rich content. Perhaps, this is where the inconsistencies are being introduced. Given a clean and pristine test like this, the only reasonable conclusion is that this is indeed a bug.

openside
10 - Mercury
10 - Mercury

ok, I did some more digging. I think I found the exact bug.

Here is my sample markdown text retrieved from API:

Test **Bold**\n\n**_Test Italic_**\n\n**_Test Code_**\n\n[Link][1]\n\n[Link 2][2]\n\n<https://espn.com>\n\nHelp\n\n [1]: https://google.com\n [2]: https://abc.com\n

If I use that exact value to perform an update into another Rich Text Field, they then become the exact same from the API standpoint. However, from the client, they are not viewed as the same via = comparison in formula.

HOWEVER, if I remove one of the \n values prior to the link settings, THEN they become identically in the client, and even the instant API returns it back with both \n\n there so that they are still equal.

So, the answer is that before updating a rich text field via API, perform a replace:

richTextValue = richTextValue.replace("\n\n [1]","\n [1]")

OR - Airtable could fix that weird bug :slightly_smiling_face:

kuovonne
18 - Pluto
18 - Pluto

Hum. I wonder what other processing Airtable is doing to rich text fields behind the scenes, and I wonder if this explains why earlier this week Scripting API said that an empty rich text field is a string containing a single line feed character (not a null like I expected).

I swear rich text is driving me bonkers right now. I really thought that copying bold/italic text used to copy the * symbols, and then it didn’t. Earlier today, I was copying checklists out of Airtable, and they copied with the [ ] and [x] when I pasted them into a plain text editor. Now they don’t.