Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[tools] fix_timepoint_data_problems: hardcoding issues #5040

Closed
cmadjar opened this issue Aug 20, 2019 · 6 comments · Fixed by #8949
Closed

[tools] fix_timepoint_data_problems: hardcoding issues #5040

cmadjar opened this issue Aug 20, 2019 · 6 comments · Fixed by #8949
Assignees
@xlecours
Labels
Category: Bug PR or issue that aims to report or fix a bug

Comments

@cmadjar
Copy link
Collaborator

cmadjar commented Aug 20, 2019

The script tools/fix_timepoint_date_problems.php hardcodes the feedback thread type to 5 on line 512 (when the default schema does not have it) and the subproject ID to 1 and 2 on line 467 which clearly is not consistent across projects using LORIS.
@cmadjar cmadjar added the Category: Bug PR or issue that aims to report or fix a bug label Aug 20, 2019
@cmadjar
Copy link
Collaborator Author

cmadjar commented Aug 20, 2019

@ridz1208 I know you went through the tool scripts. Is that issue still relevant? Copied it from redmine https://redmine.cbrain.mcgill.ca/issues/13195

@stale
Copy link

stale bot commented Jan 8, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the State: Stale PR that has had no recent activity, needs to be triaged for review or closure to proceed label Jan 8, 2020
@johnsaigle
Copy link
Contributor

I looked quickly and the subprojectID at least it still hard-coded in the script.

@stale
Copy link

stale bot commented Mar 24, 2020

The Stale label is being removed automatically because some activity has occurred or because the developers have decided that this pull request is important and should not continue to be overlooked.

@stale stale bot removed the State: Stale PR that has had no recent activity, needs to be triaged for review or closure to proceed label Mar 24, 2020
@cmadjar
Copy link
Collaborator Author

cmadjar commented Dec 6, 2022

subprojectID and feedback types are still hardcoded in the tool so still a valid issue.

@driusan
Copy link
Collaborator

driusan commented Dec 7, 2022

Can we just remove the fix_date portion of the script? If the values are hardcoded to invalid values and have been for 3 years it's clearly not being used..

@xlecours xlecours mentioned this issue Nov 14, 2023
Merged
driusan pushed a commit that referenced this issue Dec 1, 2023
@xlecours
[Tools] fix timepoint data problems (#8949)
df67123 
The script now uses 'Other' has Feedback type instead of the one with id 5 (Which was failing due to foreign key constraint if there was no feedback type with id = 5)

Also remove the part where the date of birth was determined based on the Subproject/Cohort id 1 or 2 (which does not mean anything) and now relies on Timepoint::getEffectiveDateOfBirth. I assumed that subproject 1 and 2 was making a distinction between pre ans post natal visits. Timepoint::getEffectiveDateOfBirth should handle that.

Resolves #5040
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@xlecours xlecours

Labels
Category: Bug PR or issue that aims to report or fix a bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[Tools] fix timepoint data problems xlecours/Loris
4 participants
@driusan @cmadjar @johnsaigle @xlecours