I just posted a prototype deep copy in Share Your Space that might be useful if fully productized. It’s currently hardwired to a nested 1:M project-section-task schema, but it will deep copy all levels of the schema, as well sub-projects, sections, and tasks. So, my suggestion would be (if it’s possible) to extend this prototype (or sth like it) to support: M:M relationships automatic identification of field types, names etc. I suspect this would cedrtainly have to have limits, but even the very basic prototype I wrote is useful for templating projects within a space. An alternative might be a customizable skeleton function, which folks could modify for any use case.

[image] IMTanuki: So, my suggestion would be (if it’s possible) to extend this prototype (or sth like it) to support: M:M relationships Quick question: imagine I have a space with dbs called Meeting and Topic, which are related m:m In other words, a Topic may be discussed at many meetings and a Meeting may discuss many Topics: Meeting A ↔ Topic 1, Topic 2, Topic 3 Meeting B ↔ Topic 2, Topic 4 If I ‘deep clone’ Meeting A, what would you expect the result to be Meeting C ↔ Topic 1, Topic 2, Topic 3 or Meeting C ↔ Topic 5, Topic 6, Topic 7 Now what if it was Projects and Sprints? What if it was OKRs and Workstreams? …

Hey @Chr1sG I think there are 2 potential scenarios, and each has valid use cases. Scenario 1 - each project (and its children) are standalone and unrelated to other entities in the same space, including their respective children and grandchildren. The underlying assumption in most of my use cases is that, within the same space, each top-level entity (e.g. Meeting) is copied for the sole purpose of grouping similar projects in the same space. So the result wouold be: Meeting C ↔ Topic 5, Topic 6, Topic 7 Pros relatively easy to implement Cons lower level M:M entities cannot be shared across meetings, Projects, etc. Scenario 2 - children and grandchildren (e.g. Topics and Meeting Rooms) are in shared across top-level entities (e.g. Meetings). Most enterprise-level use cases would be biased toward this scenario. And clearly, in this scenario, the result would be: Meeting C ↔ Topic 1, Topic 2, Topic 3 Pros supports coplex use cases Cons possible unintended consequences Pre-coffee Random Thoughts I’m fairly confident that, within a space, the scenarios above are fixed - that is, when copying a Meeting-Topic relationship, a new Topic will always be created, or not. But it would be consistent within a space. Maybe I’m over-engineering a possible solution, but why not define a parameter in the Advanced section of Relationships - call it Deep Copy Inheritance Bias. And for each M:M relationship, the schema designer could set the Inheritance Bias for alll entities in the same space. A deep copy function would interpret the Inheritance Bias to produce the results in the two scenarios above. You could even mix and match, such that, within a space, some M;M relationships would support creating new entities and others would not. I think this is consistent with the approach Fibery uses for other Relationship properties. Pros (again, pre-coffee) I think this approach would cover most use cases. Cons once set, the Inheritiance Bias would probably have to be read-only. But again, Fibery has this constraint when converting a 1:M relationship to M:M. I imagine this will not pop to the top of your backlog anytime soon, so I may try modifying my deep copy. In lieu of a scema Inheritance Bias, I can easily just add a constant in the init section. I hope this addresses your questions. Cheers

A general purpose cloning/deep-copy solution certainly needs a way to determine how to treat each relation “appropriately” (i.e., whether to clone the related entity, or just link the existing one).

@Matt_Blais I know this is sth you’ve thought about and worked on, so … another dimension to this problem is cycling thru each property/field in a database to determine how to copy it - boolean, single-select, rich text fields all have unique requirements. Have done anything with “auto-recognition” of each field name and type - I’m trying to figure out how to get around hard-coding both the field names and the methods to copy them…

See @Polina_Zenevich’s post here, for how to handle all the field types while cloning: [image] [✔️ DONE] Duplicate a record Ideas & Features Then I can suggest you add a Duplicate a record button slight_smile Here is the code you can use const fibery = context.getService('fibery'); const schema = await fibery.getSchema(); await Promise.all(args.currentEntities.map(async (template) => { const type = template.type; const newEntityTemplate = schema.typeObjectsByName[type].fieldObjects .reduce((result, fieldObject) => { if (fieldObject.type === "fibery/Button" || fieldObject.type === "Collaboration~Docum…

Hey @Matt_Blais ! Thx so much for posting this! This answers a lot of questions about cycling thru the schema w/o hardcoding my script. I’ll add to the next version of my deep copy script. Tweaking Fibery is becoming a FT hobby…

Deep Copy (intra-space)

Ideas & Features

Matt_Blais May 3, 2024, 7:35pm 6

See @Polina_Zenevich’s post here, for how to handle all the field types while cloning:

Topic		Replies	Views
Clone parent and child records Get Help	3	96	April 16, 2026
Intra-Space Deep Copy Get Help	15	699	April 16, 2026
Deep Copy (within a space) Fibery Showcase	2	185	May 2, 2024
[DONE] Duplicate many-to-many relations when an entity is duplicated Ideas & Features	17	793	April 16, 2026
Generic cloning of a hierarchy Fibery Showcase	10	472	May 10, 2024

Deep Copy (intra-space)

Related topics