Entity conversion from one type to another is already implemented and works really well. The default behaviour is to create a new entity of the new type and copy content fields of the same name and type from the existing entity to the new entity.
However, one of the things that does not transfer over are references/back-links. This makes sense when you are copying/duplicating an entity, but in some cases, the intent is to actually convert an entity from one type to another and replace/delete the old one (i.e. a true conversion rather than creating new and copy content). In this case the desired behaviour is to have all the back-links pointing to the new entity.
This is not a big deal if you have a few entities and only a few backlinks. But it can quickly become a nightmare if you are converting large sets of data. So I am proposing extending the convert function to provide this possibility.
I think this was discussed as part of the [APPROVED] Replace All References, but that request seemed to focus on general ability replace all references to a certain entity with a new reference (see also Search & Replace). If they are one and the same, I will combine and delete this.
I tend to do a lot of converting-to-type-then-deleting as i test, tweak, and scrap Spaces and Entities all the time, and it would be nice if references could be transferred.
We need to convert the same entity to a different entity type a lot, and never actually need to copying into another entity type that now happens.
I assume the copying of content into a new entity of another type, as happens now, may be a security measure to prevent loss of data or relations, but I did not use that feature once.
Essentially, the need is to clone one entity into another database, include all relations and all references as much as possilbe as far as fields are corresponding, and delete or archive the old entity.
It will likely need a step in between in which users can match fields so that relations and references are not lost if the databased don’t contain the same type of fields.
I would like to add a hearty vote for this feature as well. I also took the liberty to edit the title of this with the addition of “preserve references” hopefully that is OK @cannibalflea
My team has been in Fibery a while, since late 2019, and we have a lot of db hierarchy structures that are evolving, and could use some edit. This could be solved by Polymorphic Relations but I know that is some time away. We track a lot of static things, like products, service providers, equipment, etc. and some of the structures of these things need edit after 4 + years - we need another level in our hierarchy for equipment, a sub-product is now a product, or vice versa, etc. This ideally would lead to moving these older entities, with tons of references and history, into new structures. In more free-form tools like Notion or Tana I can just move those out and basically “retag” them into new DB’s with no issue. The entity stays the same and I don’t need to “convert” it to a new Type. There might be some issues with field mapping but there are simple ways those tools solve that.
However right now in Fibery the conversion feature only maintains comments as far as I can tell. very importantly all references will be lost. This means we are sitting with a lot of key entities that are core to our business - like products, etc., that are stuck in the wrong structure and we can’t move them at the risk of losing years of history.
I also wanted to repost here some other suggestions I had for more involved process in converting entities. Again I think with the degree of inflexibility within Fibery because entities are stuck in DB’s, which I would call the more “atomic” level in Fibery, vs. say another tool like Notion where the entity is the more atomic level, and DB’s are formed more loosely to essentially group entities, but the entity (or page, issue, node etc. - however the other apps refer to them) are the core base-level piece of data.
Yes I’ve seen that. I am hoping we can get this natively, it’s a lot of work for a non-coder to try to apply your solution.
I guess you could even talk about this functionality as simply “moving” an entity from one db to another. It’s a common feature of a lot of similar tools like Fibery. The entirety of the entity would be preserved, it would just move into the new DB with the requisite mapping as well.
Either way, I am really hoping we can simply get this feature soon, would really help with dealing with structures that initially seemed correct, but now need adjusting.
