Appeal History - Appeal Refactor

[thenav56]

Problem Statement

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.

Some places where it is used

go-api/api/drf_views.py

Lines 272 to 277 in 06f1bc0

	all_appealhistory = AppealHistory.objects.select_related("appeal").filter(
	country=country,
	appeal__code__isnull=False,
	valid_from__lt=now, # TODO: Allow user to provide this?
	valid_to__gt=now, # TODO: Allow user to provide this?
	)

go-api/api/drf_views.py

Lines 807 to 814 in 06f1bc0

	def list(self, request, *args, **kwargs):
	date = request.GET.get("date", timezone.now())
	queryset = self.filter_queryset(
	self.get_queryset().filter(
	valid_from__lt=date,
	valid_to__gt=date,
	)
	)

Proposal

To simplify the structure and usage, we propose the following:

1. Replace all instances where AppealHistory is used with Appeal.
2. Create a separate endpoint dedicated to retrieving AppealHistory and treat it as a separate entity.

Related Discussions/PRs

• Appeals and AppealHistory #2179
• Fix duplicate stats generation in country page #2173

cc: @szabozoltan69 @tovari @batpad @frozenhelium @samshara @udaynwa @susilnem