Change Details

Add new use cases to the donation bounded context that represent different state change actions: * Mark a donation as moderated or unmoderated. Currently, the Fundraising Application automatically moderates donations text violations and comment violations, but in the new implementation, those actions should be separated. * Soft-delete a donation or remove soft-delete status Implementation notes: The currrent implementation (mis)uses a single field for moderation and deletion - `status`. It stores the previous status as text messages in the `log` property in the data blob. The new implementation should encapsulate this behavior, but must provide a new, more high-level API - use cases where each of the actions is separate and the storage is a detail, abstracted away in the data model. When we change the database implementations, we will use separate fields in separate tables. The logic for changing the status in the Fundraising Operation Center is in `app/model/Donation.php` and `src/DonationStatusUpdateService.php`. Have a look at the unit tests for `src/DonationStatusUpdateService.php`, they should outline most of the required functionality. The controller in the Fundraising Operation Center contains another action for modifying the expiry date of the update token, but that functionlity will be removed, so no need to port it.

Add new use cases to the donation bounded context that represent different state change actions: * Mark a donation as moderated or unmoderated. Currently, the Fundraising Application automatically moderates donations text violations and comment violations, but in the new implementation, those actions should be separated. * Soft-delete a donation or remove soft-delete status Implementation notes: The current implementation (mis)uses a single field for moderation and deletion - `status`. It stores the previous status as text messages in the `log` property in the data blob. The new implementation should encapsulate this behavior, but must provide a new, more high-level API - use cases where each of the actions is separate and the storage is a detail, abstracted away in the data model. When we change the database implementations, we will use separate fields in separate tables. The logic for changing the status in the Fundraising Operation Center is in `app/model/Donation.php` and `src/DonationStatusUpdateService.php`. Have a look at the unit tests for `src/DonationStatusUpdateService.php`, they should outline most of the required functionality. The controller in the Fundraising Operation Center contains another action for modifying the expiry date of the update token, but that functionality will be removed, so no need to port it.

Add new use cases to the donation bounded context that represent different state change actions: * Mark a donation as moderated or unmoderated. Currently, the Fundraising Application automatically moderates donations text violations and comment violations, but in the new implementation, those actions should be separated. * Soft-delete a donation or remove soft-delete status Implementation notes: The currrent implementation (mis)uses a single field for moderation and deletion - `status`. It stores the previous status as text messages in the `log` property in the data blob. The new implementation should encapsulate this behavior, but must provide a new, more high-level API - use cases where each of the actions is separate and the storage is a detail, abstracted away in the data model. When we change the database implementations, we will use separate fields in separate tables. The logic for changing the status in the Fundraising Operation Center is in `app/model/Donation.php` and `src/DonationStatusUpdateService.php`. Have a look at the unit tests for `src/DonationStatusUpdateService.php`, they should outline most of the required functionality. The controller in the Fundraising Operation Center contains another action for modifying the expiry date of the update token, but that functionality will be removed, so no need to port it.