Deleting module w/ 2+ parents in split causes course to 500 in studio

Description

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).

FYI

Steps to Reproduce

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

Current Behavior

None

Expected Behavior

None

Reason for Variance

None

Release Notes

None

User Impact Summary

None

Activity

Show:
Piotr Mitros
January 10, 2015, 12:44 PM

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.

Jim Abramson
January 10, 2015, 5:31 PM

+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.

Adam Palay
January 12, 2015, 7:09 PM
Adam Palay
January 13, 2015, 2:38 PM
Fixed

Assignee

dmitchellR

Reporter

Adam Palay

Labels

Reach

None

Impact

None

Platform Area

None

Customer

None

Partner Manager

None

URL

None

Contributor Name

None

Groups with Read-Only Access

None

Actual Points

None

Category of Work

None

Platform Map Area (Levels 1 & 2)

None

Platform Map Area (Levels 3 & 4)

None

Priority

CAT-2
Configure