IARC-CSU / CanReg5

CanReg5 is a multi user, multi platform, open source tool to input, store, check and analyse cancer registry data.
http://www.iacr.com.fr/CanReg5
GNU General Public License v3.0
24 stars 13 forks source link

C202302 - Move source record to tumour record #124

Open infotel4iarc opened 1 year ago

infotel4iarc commented 1 year ago

Allow to move / copy a source from one tumour to another tumour.

cchenginfotel commented 1 year ago

Readme.md file has been updated with instructions on how to install the project. A troubleshooting section has been put in to add any additional installation issues and their solution for future installation. https://github.com/infotel4iarc/CanReg5/tree/documentation_installation

cchenginfotel commented 1 year ago
button has been added to the patient "source information" section When clicking the button, a dialog window will be displayed so the user can select where to move the selected source. After making the decision, the user clicks the "OK" button. This will close the dialog window and move the source to the previously selected tumour. If the user selects the current tumour or clicks the "close window" button, the dialog window will be closed and nothing happen. Unfortunately, the "move source" button only works on the user interface side. Meaning once the user moved the source, it will disappear from the original tumour and appear on the selected tumour. After reopening the "patient page", the previously "moved" source will be present on both the original tumour and the selected tumour. This is because the "move source" button is using the "delete source" feature, which hasn't been activated. The "delete source" feature has been commented out of the "CanRegDAO.java" file since it's not working properly. After a few tests, I noticed it deletes all previously saved sources instead of the selected one. As a result of this failing feature, the "move source" button can only act as a "Copy source" button https://github.com/infotel4iarc/CanReg5/tree/documentation_installation
cchenginfotel commented 1 year ago

To get the additional information added to the dialog window, I've added an enum to RecordEditorSourceSelectorInternalFrame.java to track which ID corresponds to which dictionary. This is not an ideal solution as it can raise potential issues with the feature if the dictionary IDs are changed. An example of an error it can lead to would be if the dictionary IDs from morphology and topography are swapped. All information from these two dictionaries wouldn't be retrieved in the dialog window unless the enum is edited to match the dictionaries ID correctly again.

To solve this issue, it would be best to not rely on the database structure and create a model within the code so the data structure would be immutable. But this would lead to a lot of refactoring.