feat: Tasks migrations and minimal ui for Create Tasks Page

[davidtaing]

This pull request setups database migrations for creating, updating and viewing Tasks and also provides minimal UI implementation for the tasks listings and task create pages.

[davidtaing]

Data (WIP)

This schema may change as I implement this feature. I will try to update this as much as possible.

Last Change Add categories table and add category_id fk to tasks

Previous Versions:

• Initial Version
• Change suburb_coordinates reference

Comments

• ¹ - suburbs and postcodes are publicly available information so we are denormalizing this and saving it in both the "public" tasks and "private" addresses tables. For updates to two tables, we can consider transactions via the RPC workaround as shown in https://github.com/codesydney/marketplace-app-for-good/pull/34/commits/11e4b909e1c861f8e33bdc32b6f9b91ddb84624f#r1646980305.
• ² - suburb_coordinates - this table will be used for the map view feature which is on the roadmap. However this isn't on the critical path, so I will hold off on further exploration for this one.

Edit:

• On second thought, the suburb and postcode fields will probably be a composite foreign key referencing the suburb_coordinates table. Noting this for later. I will continue implementing the schema described above as is.

[davidtaing]

Permissions

Tasks

Tasks represent the public listing information. Private information such as the payment status can be represented in a jobs table.

Role	Create Task	Read Task	Update Task	Delete Task
Admin	Yes	Yes	Yes	Yes ¹
Service Provider	No	Yes	No	No
Customer	Yes	Yes	Yes ²	No ³
Unauthenicated (Anon user)	No	Yes	No	No

Comments

• ¹ & ³ - ³ Instead of deleting tasks, we can update the status to cancelled. ¹ However an Admin can delete a task if it breaks the TOS.
• ² - Validation will need to be added to the API endpoint to prevent a customer from updating certain fields such as the status.

Addresses

Role	Create Address	Read Address	Update Address	Delete Address
Admin	Yes	Yes	Yes	Yes ⁵
Service Provider ⁴	N/A	N/A	N/A	N/A
Customer ⁴	N/A	N/A	N/A	N/A
Owner of Address ⁴	Yes	Yes	Yes	No ⁵
Unauthenticated (Anon user)	No	No	No	No

• ⁴ - Addresses will most likely be used in different contexts such billing addr, task addr, etc. So there's no concept of Service Providers and Customers in this table. I'm not sure if an address_type field or having multiple address tables makes sense. For now, I'll hold off on abstracting too early and will wait for a need to bubble up.
• ⁵ - See ¹ & ³ above, we'll won't be deleting addresses unless they break the TOS.

Task Categories

Role	Create Address	Read Address	Update Address	Delete Address
Admin	Yes	Yes	Yes	Yes
Authenticated⁶	No	Yes	No	No
Unauthenticated (Anon user)	No	No	No	No

Comments

• ⁶ - Logged in users should be able to see task categories but not create, update or delete them. We want this gated this since certain types of jobs such as childcare will require a working-with-children check. For now I think it makes sense not to allow any categories involving children. There could be other categories as well, but this one gets the point across.

[davidtaing]

This is getting a bit large for my liking. So I've created a new feat/tasks-pr-chain branch and will stack pull requests for this feature there.