API imported data in Long Text field only displays 20 characters

[thallisey]

When using the Airtable Import python script, fields that are imported containing markdown as Long-Text are cutoff at 20 characters (when the row height is default, double and triple - okay when quadruple). It seems the only way to eliminate this problem is open the long text editor pop-up, make any edit (and then reverse it) and then close the pop-up. It now displays as it should, full-width of the cell with the typical “…” at the end and hyperlink shortcuts at the beginning. I have a base with 1000s or records and multiple long text fields, so it would be a pain to open each record multiple times to make and reverse an edit. Is there any way to fix this in bulk? I have tried converting to short text and then back to long text. This resolves the characters being cut-off but introduces a new problem where it displays the markdown formatting in the cell instead (which is again fixed by opening the editor and making any edit). I have also tried getting the values as a formula but this still has the same issue. Also tried duplicating, copy and pasting rows, but nothing seems to fix the cut-off characters.

This screenshot shows the API imported column on the left with the cut-off text and a new long text field which copies the data from a forumla field displaying the markdown formatting.

Here is a screenshot showing the corrected cells after making any edit (I added and deleted a space at the end of the text).

(Also just to note, there is a difference in number of hyperlinks 4 vs 7, not sure why that is because it should be 7 not 4)

[rdb]

We’ll analyze the issue.

[sha]

Hi,

I can reproduce the issue. The limit of 20 characters is actually hardcoded. The preview for longtext columns is generated on the client before sending the data to the SeaTable server (when using the Airtable import script).

This limit seems arbitrary. Increasing it to 100 characters did not cause any immediate errors for me. The only downside I can see is that it slightly increases the size of the base.

I also found out that the Airtable import script does not actually render the markdown. This causes the Markdown formatting to be show in the table view in the base editor (e.g. if you have a heading right at the beginning of the cell). It is only rendered if you open the editor for the specific cell.

@daniel.pan Is there a technical reason for limiting the preview size?
Also: Can’t we just send over the plain markdown to the server and let the server handle the preview generation (e.g. just returning value inside parse_long_text() (seatable-api-python/seatable_api/convert_airtable.py at 362d57d632e455e9de0635835e0aa8c33460a3d0 · seatable/seatable-api-python · GitHub))? I did not find any issues during my (admittedly short) testing; links were still extracted and rendered properly. Thank you!

(Also just to note, there is a difference in number of hyperlinks 4 vs 7, not sure why that is because it should be 7 not 4)

This might be caused by different code paths inside the import script vs when editing a longtext column in the browser. Can you provide the specific cell content (anonymized)?

[thallisey]

I also found out that the Airtable import script does not actually render the markdown. This causes the Markdown formatting to be show in the table view in the base editor (e.g. if you have a heading right at the beginning of the cell). It is only rendered if you open the editor for the specific cell.

Yes I thought this as well, but then it seems that (at least in my case) it wasn’t consistent. Sometimes it was rendered and sometimes it wasn’t. It seems it mostly likely isn’t rendered when there were multiple formats (i.e. bold and italic, or bold and hyperlink). Also in our case, sometimes the first line will be something like this: **Here is an example first line ** in which the markdown code is rendered instead of the preview. It seems like almost 100% of the time there is an extra space before the second **. Could be just the way our data was created in Airtable originally (I think might happen when copying and pasting from Word or Outlook). Interestingly in opening the the editor and adding an extra space after the second ** the preview will automatically appear (despite not having deleted the extra space before the second **). The markdown will still be displayed even in the editor, however other markdown in the same text will be rendered correctly (hyperlinks, other formatting, etc.) On the other hand, there are instances where hyperlinks appear in the preview text, these are rendered as preview and not markdown code (however there is a second issue, where because the hyperlinks are converted to the “numbered” links, the actual hyperlinked text disappears from the text, but this seems to be a general issue with the long text field and not related to the API imported data).

This limit seems arbitrary. Increasing it to 100 characters did not cause any immediate errors for me. The only downside I can see is that it slightly increases the size of the base.

Is it possible for me to do this (or use a modified version of the convert_airtable.py directly)?

Can you provide the specific cell content (anonymized)?

Unfortunately, due to the nature of data, I don’t feel comfortable with that, but I would be happy to show you somehow privately.

In the end it would be good to find away for the cell previews in the base editor to display correctly after already having imported the data without having to open the editor for each.

[sha]

@thallisey

I also found out that the Airtable import script does not actually render the markdown. This causes the Markdown formatting to be show in the table view in the base editor (e.g. if you have a heading right at the beginning of the cell). It is only rendered if you open the editor for the specific cell.

Yes I thought this as well, but then it seems that (at least in my case) it wasn’t consistent. Sometimes it was rendered and sometimes it wasn’t. It seems it mostly likely isn’t rendered when there were multiple formats (i.e. bold and italic, or bold and hyperlink). Also in our case, sometimes the first line will be something like this: **Here is an example first line ** in which the markdown code is rendered instead of the preview. It seems like almost 100% of the time there is an extra space before the second **. Could be just the way our data was created in Airtable originally (I think might happen when copying and pasting from Word or Outlook). Interestingly in opening the the editor and adding an extra space after the second ** the preview will automatically appear (despite not having deleted the extra space before the second **). The markdown will still be displayed even in the editor, however other markdown in the same text will be rendered correctly (hyperlinks, other formatting, etc.) On the other hand, there are instances where hyperlinks appear in the preview text, these are rendered as preview and not markdown code (however there is a second issue, where because the hyperlinks are converted to the “numbered” links, the actual hyperlinked text disappears from the text, but this seems to be a general issue with the long text field and not related to the API imported data).

We’ll check this and get back to you.

@thallisey

This limit seems arbitrary. Increasing it to 100 characters did not cause any immediate errors for me. The only downside I can see is that it slightly increases the size of the base.

Is it possible for me to do this (or use a modified version of the convert_airtable.py directly)?

Are you running the import script inside Seatable? Or on your host?

[thallisey]

Thanks, I am running it inside SeaTable. While it would be great to address the hardcoding in the python script for others, at this point for me, it is mostly already done (except for one project with a lot of rows). I am now looking for a way of just fixing the preview text. I have already migrated 24 projects which contain this long-text issue and it wouldn’t be possible to try to re-import them from Airtable as the original projects no longer exist.