Modules with Programmes from outside the WorkPackage cause clone errors about wam HOT 3 CLOSED

Unit tests and further investigation seem to show this is a red herring. So closing for now.

from wam.

On second thoughts, that's a stupid idea. Renaming the bug. It would appear the culprit was a module with one of its programmes from outside the WorkPackage. This shouldn't happen, and could only happen from using the Django built in admin to change the programmes. However, that is still available currently.

Best workaround: ensure staff use the custom admin rather than generic Django admin.

Further work needed: how to resolve this when really it's a data integrity issue.

__clone_programmes() currently (and correctly) only examines programmes from the source package, building up a mapping in programme_mapping() as it clones each one.

When the modules are cloned then if a module has a programme from outside the package there will be no valid mapping for this. It might be cleanest to simply remove the mapping from the destination package, and flag this as a warning in the clone process.

from wam.

A unit test was added that was tripped by this issue by deliberately moving a module to an alternative source package. The cloning logic was then adapted to only attempt to remap programmes where a mapping existed. The upshot is any links to programmes not in the correct source package (they all should be) will be severed in the cloning process and an error logged, but the clone process should then carry on regardless.

from wam.