Unless I am missing something, it seems like a real hazard for the Rich Text Field contents to be openly editable on Entities created by Integrations such as with Discourse or Integromat. At a very minimum it is unclear what the consequences of doing so will be. Obviously without Bi-directional integrations/sync, an edit should not propagate back to the source app. And since there is as yet no answer to my question about What happens when an integration is updated/expanded?, I am unsure if edits will be preserved if/when the Rich Text is updated via the Integration, or what.
This confusion and uncertainty could be avoided by simply making this Rich Text Field uneditable. Which is exactly how all other default Integrations fields are treated AFAIK, and this makes good sense. Given that you can’t sync back any changes, you shouldn’t be able to make changes to this data in Fibery. You can of course create new fields on Integrations Types, which you should be able to edit, or create Links to other Entities, or Relations, all of which should be able to address any need that was possibly met for some by being able to edit this Rich Text content.
I realize that the reason it is this way may be simply due to a limitation in the Rich Text Field “type” itself. In which case I just think that should be remedied.
All integrations just Append text to the rich text field. So if you delete all the content, the next sync will just add NEW content and will not bring back old content.
We have to keep these fields writable to add references and bi-links.
Not sure how it can be fixed so far. In the future rich text integration will be replaced by Blocks. Not sure about blocks editing so far…
Ah, I see. Being able to add References and Bi-Links to otherwise non-editable content seems like a useful thing to me. But given the move toward Blocks it may not be worth it to implement now. I guess if nothing else I would just suggest that, as you consider how to setup the Block system, and how it will interact with Integrations, it would be ideal to have the ability to have non-editable Blocks that still let you reference, link, etc. with them. That serves the original point of this request, which I still think is important.
I’m glad you clarified how the integrations work, but AFAIK this info is not available anywhere else but here in the forums and will not be known by most people I think. Thus the potential for confusion remains.
So far we are working on concepts, development should start in about 2 weeks. Hard to say when we’ll release something, but most likely it will take us 3-4 months
Blocks, most likely, won’t be a silver bullet here, since they will transform the problem, not solve it:
Linking of arbitrary pieces of text to Entities will be gone, so there will be no need to edit the document content
On the other hand, users will slice a single Intercom message into multiple Blocks to link them to Entities. Can we make the Blocks themselves read-only while keeping the opportunity to slice and merge Blocks?
To be honest, I’m not sure if the problem is that serious. I understand the risks but we’ve made an effort to preserve the changes made in Fibery. This decision even came at a cost: in “appendable” connectors (Intercom, Zendesk) we don’t update messages if they are edited in the source after being sent.
Because then we’ll have to somehow merge Fibery updates (ex. pieces of text linked to another Entity) with source updates. This is a non-trivial operation prone to errors.
Instead, we just ignore those late edits. So far we haven’t heard of scenarios where this is a deal-breaker.
OK, that makes sense. In general I don’t think it’s a huge issue, I just like to have the latest data. Maybe there will be a better solution in the future.
Maybe there will be a better solution in the future.