Gotcha. So to really try to resolve this I’d probably need more info, and you’re probably right that versioning would help create a more ideal solution. However, without knowing more, I can see at least two other possible approaches off-hand, aside from copying the test case into the execution entity (and there may be more with some more thought and/or knowing more about the workflow).
1: Define the test cases in a Rich Text field, with check boxes or whatever you prefer. And delineate each version with a header (H1), e.g. “Assembly test case #45 V1.0”. Then somewhere in the body of that section of the text, link to the Test Execution Entity for when you run that test. When you update the test case, copy/paste everything you want to update from it, create a new header “Assembly test case #45 V2.0”, collapse the previous one, and paste in the V1.0 contents and update. A little manual work, but not too bad, and you keep all the versions in one place.
I’ve shown a pseudo-example in the image below. Obviously I’m linking to the wrong entity, in this case the Test Case itself. You can see the previous test case is collapsed at the bottom. I just copy/pasted the bottom one to make the top.
2: Another option might be to create a “self” relationship in a 1:1 configuration for the “Test Case” Type and name the two resulting fields “previous version” and “next version”. Then when you need to update the test case, create a new version and link to it in the “next version” field, copy the contents of the old, go to the new, paste, and edit as-needed. Any Executions of that version of the Test Case get linked as normal in their own 1:1 relationship field. Again shown in my example image, this time outlined in blue, and obviously the relationship to “tasks” here in my test Type would for you be a link to the “Test Execution”.
Obviously all of these involve steps like copy/paste which you might see as being too much work for your needs. And these ideas may be totally non-workable, or just not an improvement on what you’re already doing. One thing I’ll say that I think this makes clear is that a “copy entity” function would be nice.
Part of what would be good to know to try to come up with better options is what really are the “pain points” of your existing workflow, i.e. what takes the most time/effort and what other problems arise from these versioning issues, how often does versioning happen, how many maximum versions are you likely to have, etc.
I’m also curious if any existing tools that you know of already handle this well and could be used as a good model.
Having said all that, I definitely want document history and possibly versioning, i.e. named versions. I’m just less confident about how to best handle the complexities of maintaining history on relationships, backlinks, etc.
I suppose one simple option for dealing with e.g. a deleted entity would be to maintain the name of it in any entities it was linked to, in their history state, and the live link just doesn’t work. Or, alternatively, to maintain a read-only archive of the deleted entity in the state in which it existed when it was linked from the version of the entity you’re looking at. But even trying to describe issues like this starts to make my head spin and is one reason I’m wary of wanting to rely on this kind of deep and complex version handling.
I’m glad I don’t have to actually implement solutions to these problems and trust that @mdubakov and team will make good choices moving forward. They have done well so far.