LF-4531: Set up new task abandonment reason for tasks with removed animals

[SayakaOno]

Description

This PR adds support for the new abandonment reason when all animals are removed from a task. The key will be added as part of delete/remove animals/batches APIs.

• Add a migration to add constraint to validate the abandonment_reason in the task table. (This wasn't necessary, but I added it to avoid adding a wrong key. Wrong keys don't exist in the prod or beta DB, so it should be safe to add this constraint.)
• Add a translation key for the new reason
• Add the new reason to TaskModel
• Add the checkAbandonTask middleware not to allow the new key to be added from clients
• Add a test

This task was simpler than expected since the keys are hard-coded in the webapp, and the read-only page and task creation page don't share the same code.

• Creation
  

  LiteFarm/packages/webapp/src/components/Task/AbandonTask/index.jsx

  Lines 164 to 178 in aa4be4f

  	<Controller
  	control={control}
  	name={REASON_FOR_ABANDONMENT}
  	render={({ field }) => (
  	<ReactSelect
  	options={abandonmentReasonOptions}
  	label={t('TASK.ABANDON.REASON_FOR_ABANDONMENT')}
  	required={true}
  	style={{ marginBottom: '24px' }}
  	{...field}
  	placeholder={t(`common:SELECT`)}
  	/>
  	)}
  	rules={{ required: true }}
  	/>

• Read-only

LiteFarm/packages/webapp/src/components/Task/TaskReadOnly/index.jsx

Lines 350 to 371 in aa4be4f

	{isAbandoned && (
	<div>
	<Semibold style={{ marginBottom: '24px' }}>{t('TASK.ABANDONMENT_DETAILS')}</Semibold>
	<ReactSelect
	label={t('TASK.ABANDON.REASON_FOR_ABANDONMENT')}
	required={true}
	style={{ marginBottom: '24px' }}
	isDisabled={true}
	value={{
	label: t(`TASK.ABANDON.REASON.${task.abandonment_reason}`),
	value: task.abandonment_reason,
	}}
	/>
	{isOtherReason && (
	<InputAutoSize
	style={{ marginTop: '40px', marginBottom: '40px' }}
	label={t('TASK.ABANDON.EXPLANATION')}
	value={task.other_abandonment_reason}
	disabled
	/>
	)}

Jira link: https://lite-farm.atlassian.net/browse/LF-4531

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Replaced abandoned task's abandonment_reason with NO_ANIMALS in the DB and checked the read-only page in the webapp.

• Passes test case
• UI components visually reviewed on desktop view
• UI components visually reviewed on mobile view
• Other (please explain)

Checklist:

• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• The precommit and linting ran successfully
• I have added or updated language tags for text that's part of the UI
• I have added "MISSING" for all new language tags to languages I don't speak
• I have added the GNU General Public License to all new files

[kathyavini]

Sorry could you elaborate on why you wanted to add the database restriction at this particular stage? I understand it's definitely ideal to restrict at multiple levels, but I'm thinking about that "Crop management plan abandoned" translation ticket coming up, which I think will also require creating a new key, and so that migration would end up deleting and re-creating this check too, then, correct?

Only to restrict the number of database migrations, I wonder if continuing to let the model validation enforce for now would be okay? Or is there a particular danger the model isn't catching?

[antsgar]

Similarly to how we do this now for other entities, I think the best way to solve the problem of disallowing wrong keys at the database level would be to have an enum table for the abandonment keys, and have the reason column have a foreign key to that table. Would be similar to what's happening now with animal movement purposes, or animal uses. I'm not sure if that migration would be trickier though due to us already having existing data, so we don't need to do this now! But just proposing that as a longer term solution