Great! I’ve heard back from their forums and pretty much the only way to get around this is manual insertion. They suggested PHPMyAdmin.
That would require deploying it and maintaining it, so I don’t think we really want to do that if we don’t have to, so unless it’s a big issue, I’d rather not try to solve this directly. Instead, I’ve improved the importer script and run it once more so that the text it imports into the non-WYSIWYG field is better. In most cases it should be functional markdown.
If the result is good enough for your client’s tracking, feel free to keep it as-is. If it isn’t, since the text should be markdown, I’d suggest just grabbing a browser-based renderer (such as your IDE’s Markdown support or this forum’s post preview – though make sure to delete the contents after on that last one!) and then copying and pasting the rendered text into the WYSIWYG editor.
I’ve also blanked all the WYSIWYG field of all the imported notes, since it looks like @Agrendalath moved his relevant ones over and the rest would have contained garbage from the import. If you had managed to edit/fill something in this field for an imported note over the last day or so, sorry about that! You’ll need to make your change again. From this point forward, if I have to re-run the import script for some reason, I’ll only be targeting the non-formatted field.
If all else fails, there is a full export of Monday’s data on drive.
Gotcha. This will probably need to be investigated in a follow-up task, since it will probably involve customizing how the deployment works-- this is deployed on Kubernetes via helm, but apparently customizing the CSS in a persistent matter requires adding some files. Unlike WordPress, SuiteCRM does not have a built-in plugin manager/installer, so we can’t just pull a CSS modification plugin from the net. Searching ‘css’ on their plugins page doesn’t yield anything, either.
Alternatively we could force it via browser extension. But that’s not elegant. In any case, I’ve created a ticket for the work to change the CSS and put it under the automation account since I don’t think it needs to fit under the migration’s scope. I’ve assigned it tentatively to @demid since it’s something that, if it has to be delayed for a while due to the ongoing conflict, it won’t cause problems. However feel free to reassign as needed.