Generic cloning of a hierarchy

[Chr1sG]

Following a bit of discussion here in the community about duplicating hierarchies of entities, I put together a space which can be used to clone a top-level entity and all its children, grandchildren etc.

At the moment, any items linked via a one-to-many relationship will be cloned (as will any items linked to them via 1:m, and so on…)

m:m, m:1 and 1:1 relations are ignored, with the exception of m:? relations to users (e.g. Assignees, Owner, etc.).

---

Once you have installed the space, go to the ‘High level goal’ Objective and find its UUID.

Copy this into the UUID cell in the Clones table, and tick the trigger box.

You should get a perfect clone of the entire hierarchy from Objective through Project to Tasks.

Now try adding a row to the Clones table with the full name of another database in your workspace, and the UUID of a specific entity in that database, and trigger this one.
Fingers crossed.

---

It’s not been tested thoroughly so please play with it and provide feedback.

Note: because there is no limit on the depth of cloning, it is possible for it to get stuck in a never ending loop
e.g. if you have these relations
Project A → Task 1, Task 2
Task 1 → Project A, Project B
and you try to clone Project A, it will never terminate.

If this happens, you’ll need to disable the automation.

[Matt_Blais]

@Chr1sG

it is possible for it to get stuck in a never ending loop

I would expect the script to terminate with an error message when max script CPU time of 1s is exceeded (or max clock time of 60s).

[Chr1sG]

@Matt_Blais

I would expect the script to terminate with an error message when max script CPU time of 1s is exceeded (or max clock time of 60s).

I don’t think it will.
In my template, the script runs, and one of the effects can be to create additional records, and the script then starts to run on these records.
Each individual script execution is under 60s.

[Matt_Blais]

How does that not trigger the dreaded loop detection?

automation script → creates new entity → triggers same automation

I had to go to extreme lengths to work around that problem: cloning the entire tree in a single script execution.

[Chr1sG]

New template - Finance

In your case loop should be detected as per algorithm I’ve described above. (Un)Fortunately there is a bug in current implementation, that breaks loop detection for operations called from js scripts. So if you make a change from JS script, that chain I’ve described above is broken and starts anew. Some day I will fix it and your rule will break For scripts we can improve though, and check actual fiberyApi calls from scripts, if they are duplicated in a chain. Cannot promise…

[Matt_Blais]

Huh… when loop detection was initially implemented it broke my original cloner system, which worked the same way as what I think you are doing:

automation script → creates new entity → triggers same automation

Now I cannot find the old thread where I complained about that change breaking my original cloner script

[IMTanuki]

@Chr1sG - thx for putting this together! I need to do a deep dive over the weekend, but lots of interesting ideas in your code…

Any chance this will make it into the backlog as a std feature?

Will you be extending this to support M:M?

[Chr1sG]

@IMTanuki

Any chance this will make it into the backlog as a std feature?

It’s not planned in the short-term roadmap

@IMTanuki

Will you be extending this to support M:M?

Originally, I did include support for m:m, but the method I used can give problems if you try and clone a hierarchy via m:m relations.

Imagine having dbs A, B and C linked
A 1:m B
B m:m C

If entity A1 is linked to B1 and B2, which are both linked to entities C1 and C2, the method I created in the template above would cause ‘excessive’ duplication:
Cloning A1 would trigger cloning of B1 and B2. Cloning of B1 would trigger cloning of C1 and C2, but then so would cloning of B2.

So the resulting new entities would be

A1, B1, C1, C2, B2, C1 and C2

It would be possible to modify the script to add linking to existing entities for m:m relations, but I wasn’t sure how useful this actually would be, apart from relations to users.

[IMTanuki]

I think the trick would be to maintain a temporary list of all cloned children in a M:M relationship with their respective original/new id’s to avoid the dup you’re describing.

My next step would have been to update my deep copy template to recognize and process fields w/o hard-coding and you’ve basically solved that for me, so I will take a shot at the M"M, hopefully sometime soon.

[Chr1sG]

@IMTanuki

I think the trick would be to maintain a temporary list of all cloned children in a M:M relationship with their respective original/new id’s to avoid the dup you’re describing

Yeah, that would be one way, but I was trying to go after a simple method that would scale to any possible hierarchy size.
Tbh, even with the current method I have, a hierarchy that looks like this

A → B
B → C
A → C

could cause problems.

[IMTanuki]

Haha - why use a simple method, when you can over-engineer it…that’s what I always say…

Anyway, I was thinking of creating a 2-dim array (dim 1 corresponds to each database, dim 2 for each entity in that db) to track the copied status (of each entity). Then, as you iteratively go thru each entity and clone its immediate children, check the array to see if a new instance of a child has already been created - if not, create it and upd the array, then in both cases, point to the child entity.

This assumes, of course, that you’re cloning a true template with a minimal num of records and not some massive db…