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.
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
Updates to parent results framework not propagated to children correctly #2951
Comments
punchagan
added a commit
that referenced
this issue
Nov 8, 2017
punchagan
added a commit
that referenced
this issue
Nov 8, 2017
punchagan
added a commit
that referenced
this issue
Nov 8, 2017
punchagan
added a commit
that referenced
this issue
Nov 9, 2017
The bug in #2951 caused some corrupted data to be stored in a UTZ project. This script essentially cleans up the mess, and recreates the data correctly. This script, though, seems to run needlessly slowly. There might be scope for some optimization in the child/parent detection code.
Closed in #2952 |
punchagan
added a commit
that referenced
this issue
Nov 9, 2017
The bug in #2951 caused some corrupted data to be stored in a UTZ project. This script essentially cleans up the mess, and recreates the data correctly. This script, though, seems to run needlessly slowly. There might be scope for some optimization in the child/parent detection code.
zzgvh
added a commit
that referenced
this issue
Nov 9, 2017
…imported-results-framework [#2951] Data fix script for UTZ Code reviewed
punchagan
added a commit
that referenced
this issue
Nov 9, 2017
punchagan
added a commit
that referenced
this issue
Nov 10, 2017
When the results framework is imported from a project to it's children, each child project should have only one child per result/indicator/period, and no more. This commit enforces this constraint in the DB.
punchagan
added a commit
that referenced
this issue
Nov 10, 2017
When the results framework is imported from a project to it's children, each child project should have only one child per result/indicator/period, and no more. This commit enforces this constraint in the DB.
punchagan
added a commit
that referenced
this issue
Nov 10, 2017
When the results framework is imported from a project to it's children, each child project should have only one child per result/indicator/period, and no more. This commit enforces this constraint in the DB.
punchagan
added a commit
that referenced
this issue
Nov 10, 2017
When the results framework is imported from a project to it's children, each child project should have only one child per result/indicator/period, and no more. This commit enforces this constraint in the DB.
punchagan
added a commit
that referenced
this issue
Nov 15, 2017
unique_together constraint seems to make the fields that are a part of it hidden, even when they are marked as read_only. This commit adds a work around, to fix this bug. Using the patch from encode/django-rest-framework#4192 didn't seem to work. There are other changes, possibly, that cause this code to not work in the version of DRF we are using.
punchagan
added a commit
that referenced
this issue
Nov 16, 2017
When the results framework is imported from a project to it's children, each child project should have only one child per result/indicator/period, and no more. This commit enforces this constraint in the DB.
punchagan
added a commit
that referenced
this issue
Nov 16, 2017
unique_together constraint seems to make the fields that are a part of it hidden, even when they are marked as read_only. This commit adds a work around, to fix this bug. Using the patch from encode/django-rest-framework#4192 didn't seem to work. There are other changes, possibly, that cause this code to not work in the version of DRF we are using.
5 tasks
zzgvh
added a commit
that referenced
this issue
Nov 16, 2017
…ts-framework-children [#2951] Disallow multiple result/indicator/period children per project Code reviewed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Creating a new period/indicator on a parent results framework doesn't create the children periods/indicators correctly, though the code intends to do so. This either needs to be fixed, or the code removed to avoid breaking things.
The text was updated successfully, but these errors were encountered: