-
Notifications
You must be signed in to change notification settings - Fork 20
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
IATI partner types #1633
Comments
[fixes #1633] IATI partner types
@zzgvh taking another look at this |
The PartnerType model was used to limit the types of partners that could be added by an organisation. This is now obsolete.
Simplificate the code, remove duplicate listing of partner type and fix punctuation and capitalization.
Partnership.partner_type Initial sweep of the code to move uses of partner_type to the new field iati_organisation_role. Missing is the migration to create the new field. I'm having problems that seem reated to multiple import paths.
The import of Partnership in iati/elements/participating_org.py at the module level causes a runtime error when trying to create a new migration for the Partnership model. Fix by moving the import into the function where it's used.
Also revert imports of Partnership that were changed when trying to fix the dual import problem.
Remove filtering key/value from PartnershipResource.Meta.filtering Add comment to Partnership model
A number of keywords are duplicates in fuction. This migration looks for the "old" keywords and replaces them with the "new" one.
Add some more diagnostic output Fix label characters
Keywords that aren't used in any project are deleted.
To prepare for the removal of sponsor partners, create a keyword for each organisation that is a sposor partner. The keywords are of the format <org ID>:<org name> to distinguish them from "ordinary" keywords.
Notes on the migrationsAbove are three migrations managing the keywords.
The number at the end of each line being the number of projects tagged with that keyword. We can see discrepancies between the sponsor partner keywords and the corresponding regular ones. Example: 272:Connect4Change 85 and Connect4Change 101. |
Enable filtering on legacy Partnership.partner_type(_2) values in the Tastypie PartnershipResource NOTE: when the Partnership.partner_type field is removed, all references to partner_type_2 should be changed to partner_type
- Renamed partner_type_2 to partner_type - Changed the backwards compatible Extending partner to 'extending', since converting this to a support partner isn't completely correct. Also, it gave issues when trying to filter on 'support' in the API, since it then only returns the partners with the accountable role and not extending. 'Extending' isn't fully backwards compatible though, because this type didn't exist before, but only new partner could have this type.
Test planThis is a fairly large change in how projects are organized and how we differentiate partner types. Changes:
Since much of this work is related to the live data set, I think testing this requires a fresh copy of it. It might be best to compare a the test database before and after applying the migrations in this branch. Testing the migration of partner_type to iati_organisation_roleGIVEN a fresh copy of the live RSR DB Testing of keywordsThis is harder to "pin down". In the Notes on the migrations post above you can see a sample list of keywords and the number of projects for each after the migrations have run. This list is printed so it should be visible in the deployment log. None of the duplicate keywords should remain, and there should be a list of new keywords on the ID:org_name form similar to the above. More detailed testing requires writing SQL tests I think. Testing the APIsIt would be very useful if we could find out how the API is queried regarding partner types to see if there are use cases that we don't cover after the migrations. The APIs look almost the same, you can still query for Partnership.partner_type, but it is not 100% identical so there might be edge cases that we don't support any more. OTOH it's unlikely that anyone uses the API like this, but it'd be good to make sure. The primary resources to find out how they're used are |
akvo/akvo-product-design#84
The text was updated successfully, but these errors were encountered: