Currently, we have two entities: Appeal and AppealHistory, with the latter used to track changes to Appeal. We have replaced Appeal in all aggregated data and listings where Appeal was originally used. While valid_from and valid_to attributes in AppealHistory allow us to fetch data for specific time periods, these attributes are not utilized within the system itself but only at the endpoint level. This has resulted in a complex structure for endpoints where both Appeal and AppealHistory are needed for calculations, requiring manual definition of valid_from and valid_to attributes.
Problem Statement
Currently, we have two entities:
AppealandAppealHistory, with the latter used to track changes toAppeal. We have replacedAppealin all aggregated data and listings whereAppealwas originally used. Whilevalid_fromandvalid_toattributes inAppealHistoryallow us to fetch data for specific time periods, these attributes are not utilized within the system itself but only at the endpoint level. This has resulted in a complex structure for endpoints where bothAppealandAppealHistoryare needed for calculations, requiring manual definition ofvalid_fromandvalid_toattributes.Some places where it is used https://github.com/IFRCGo/go-api/blob/06f1bc065b43b32b6b57a38dca4e5633e2c6487c/api/drf_views.py#L272-L277
https://github.com/IFRCGo/go-api/blob/06f1bc065b43b32b6b57a38dca4e5633e2c6487c/api/drf_views.py#L807-L814
Proposal
To simplify the structure and usage, we propose the following:
AppealHistoryis used withAppeal.AppealHistoryand treat it as a separate entity.Related Discussions/PRs
cc: @szabozoltan69 @tovari @batpad @frozenhelium @samshara @udaynwa @susilnem