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
Orphaned indicator periods #2528
Comments
I was trying to get a list of all the child projects of ids = [p.id for p in Project.objects.get(id=3980).children_all()]
for id_ in ids:
print id_
for indicator_period in IndicatorPeriod.objects.filter(period_start=None, indicator__result__project_id=id_):
print indicator_period.indicator.result.title
print indicator_period.indicator.title
print indicator_period.parent_period().period_start I found a bunch of indicator periods on the project
Notice that the |
Looks like this bug was accidentally introduced in this commit that was merged with #2298 (quite recently). There aren't too many indicators (68) where this problem is present, since the bug is pretty new. Most of them seem to be in WASH alliance projects. for indicator_period in IndicatorPeriod.objects.filter(Q(period_start=None) | Q(period_end=None)).exclude(indicator__result__parent_result=None):
project = indicator_period.indicator.result.project
print "|{}|{}|{}|".format(indicator_period, project.id, project.title)
|
…riod Use foreign keys to indicate parent Indicators and IndicatorPeriods for for child projects. Refactor the code to use the foreign keys to find parents and children
I've made the refactoring to use FKs for Indicators and IndicatorPeriods relations to parents. A little tweaking of the tests were required to make them pass but I think they are legitimate changes. What's missing is a thorough search of the code to see if I've missed places that fiddle with the results framework. And a migration strategy that assigns FKs to all current objects in the live DB 😛 And maybe more tests 😉 |
Also, resolve conflicting migration files.
Since child periods now have FKs of the parent, deleting the parent will automatically delete them.
Saving parent takes care of fixing target_value, etc. if it can.
Also, make the migration runnable backwards
Also, make the migration runnable backwards
The methods checking if an indicator or period is a child in a results framework should now use the FKs to parent indicator/period objects.
It should not be possible to create an indicator period for an indicator that part of a child result. Resolve by hiding the link in the project editor.
Set `LC_ALL=C` in `manage.sh` since that is what the server seems to have, and this should help detect such problems in the future.
Set `LC_ALL=C` in `manage.sh` since that is what the server seems to have, and this should help detect such problems in the future.
Closed in #2530 |
Some editing actions in the Results framework may lead to indicator periods in child projects becoming orphaned. This can happen in at lest two ways:
If an indicator period of a child project, that has inherited results from a parent, is deleted and then recreated, it will not become a part of the parent-child relation even if the dates are set to be the same as originally. Instead an error message is shown for the date fields and they then become empty and in-editable when reloading the project.
If an indicator period of a parent project is edited to change the period start and/or end dates, any imported period in a child will be similarly orphaned.
In both cases the actual value or updates made in the child will not be imported to the parent. Also the Import results button on the child becomes disabled and cannot be enabled again even after removing the Result and the parent relation in the child and then putting the relation back.
I have not yet fully investigated the cause of these problems, but they are probably connected to the fact that parent-child relations is maintained in part by filtering on the period date fields and when they don't align the link may be lost.
The text was updated successfully, but these errors were encountered: