chrisknoll
commented
1 year ago Some implementation notes:
There's 2 parts to this:
Information
To inform the user which analyses are using the cohort definition because the user may decide not to delete the cohort when they see how it's used.
Quality of LIfe
Sometimes a cohort definition is shown to be invalid or obsolete so you just want to delete it regardless of where it is used. Being able to 'detach' the cohort definition from analyses before deleting saves the trouble of having to go into each analysis and do it one-by-one.
There are some considerations for this: while you may have permissions to delete the cohort definition, you may not have update permissions on the analyses that are referencing it, and therefore you may not be allowed to edit the analysis to remove the cohort definition reference. Should this be a special 'back door' case where if you detach a cohort definition, you are permitted to change those analyses, or should the analysis owner be the judge on if a cohort definition should be removed or not? If it is the latter, then at least the Information section of this issue will inform the user as to which analyses are referenced and to ask the analysis owner to modify their design so that the cohort can be deleted.
Expected behavior
When you delete a cohort definition, if there are associated analyses that use this cohort definition, you should be notified of those references.
In addition, should be able to easily 'detach' cohort definitions from other analyses so you can delete the cohort.
Actual behavior
If you delete a cohort definition that has a foreign key (FK) to an analysis design, you are notified that you are unable to delete, but no further information is offered. You have to go through logs looking for the FK violations, and what tables are violating, and then do additional queries to look up with analyses reference the cohort definition-to-delete. Then you need to edit each analysis to remove the cohort def, and then finally delete the cohort itself.