We encountered an issue in where deleting a discussion module with multiple parents (in a split course) causes that course to throw 500 errors when trying to access it in studio.
Here are 3 solutions that offers:
1. when cloning/importing into split, copy the block for each duplicate reference like xml does for problems and some other types and ensure it's a true tree
2. when cloning/importing into split, generate a warning and then assign the shared block to only one of the parents removing it as a child from the others thus ensuring it's a true tree
3. when deleting a component, do the extra work to remove it from every parent pointer not just the known one & allow the course to be a non-tree (with the get_parent ambiguity from the other thread).
1) Create a course in studio with two verticals (v1, v2)
2) in v1, create a discussion (d)
3) export the course
4) Edit the xml for v2 so that it also points to d. (you can copy-paste the contents of v2 to v1)
5) tar the course and import it
6) in studio, go to one of the verticals, and delete the discussion module there
7) Refresh the page and see 500 error
I'm not sure (1) and (2) are bug fixes; just bug shifts. From users' perspectives, the course will behave in different and unexpected ways after clone/import. (3) would resolve the bug, if performance, implementation time, etc. is okay.
It seems like this might effect a very small number of courses. If so, additional alternatives in case (3) is not feasible:
1. Signal to the user what the issue is, fail on clone/import, and manage manually.
2. Identify all the courses which might be effected, proactively contact the course staffs, and convert those to trees.
+1 for option 3 as the correct fix. Even if we begin to enforce the tree structure more strictly, deletion of components should do the right thing with the data we know we already have.
Also agree with identifying the affected courses proactively (alternative no. 2) to put out warnings to staff before we get another prod incident.