[Doctrine DBAL will remove its event system in version 4.0](https://github.com/doctrine/dbal/issues/5784) and logs deprecation warnings whenever code uses the event system. Our code uses the event system to generate access and update tokens for donations and memberships when they are saved. To avoid filling our log files (making debugging harder) and be ready forwith deprecation warnings (which make debugging harder because they clutter the log files and may lead to false assumptions) and make our code ready for updating to Doctrine version 4, we need to change the way how and when we store security tokens.
**Background information**
When we wrote the Fundraising Application and created the domain model, we did not want to "pollute" our domain object (Donation) with HTTP-specific access control properties, so we opted for "sneaking them in" through the Doctrine entity when the donation is saved.
**To discuss:**
Do we want the general concept of access control (in this case "the owner has a token that allows them access") inside our use cases? If yes, we need to pass an interface into the `AddDonation` and `AddMembership` use cases that'll allow us to create the credentials. If not, then we need to remove the Authorizer classes from the use cases that need it (GetDonation, AddComment, etc.)
The `TokenFetcher` dependency of the use case exposes the existence of tokens to the domain. Maybe we should take the opportunity to remove the `TokenFetcher` dependency, not return tokens in the value object of the use case return and read the tokens in the controller (where they belong, since they are access tokens for the HTTP layer).
How to split this ticket. Suggestion: 43 tickets (donation bounded context, membership bounded context, integration in Fundraising App, integration in FOCundraising App)
**Acceptance criteria:**
- The deprecation warning for the event system no longer occurs
**Non-Goals:**
- Extracting the access tokens from the data blob in `spenden` into their own table - This would be too much effort right now. However, make sure that there is only one class (or at most two) classes, if we decide to keep `TokenFetcher`) for interacting with the database, so they can be swapped out in the future.
**Implementation details:**
When the integrating the changed bounded contexts into the fundraising app and the Fundraising Operation CenterApp, you can remove event-related code from `ContextFactoryCollection`, `DoctrineFactory` and `FunFunFactory`. In `FunFunFactory`, `getPlainEntityManager` can become the new `getEntityManager`.
The Fundraising Operation Center does not need any changes - it doesn't call the "Add Donation" and "Add Memership" use cases and doesn't initialize Doctrine with event subscribers.
Suggested Approach for generating tokens inside the "create" use cases:
1. Add a new method to the `DonationAuthorizer` and `MembershipAuthorizer` interfaces in the bounded context. In domain terms, the new method should "authorize the owner", e.g. `authorizeOwner( $donation )`.
2. The Doctrine implementations of the method can copy the code from the event subscribers (e.g. `DoctrineDonationPrePersistSubscriber`) to generate the tokens with the help of a token generator
3. Inject the Authorizer interfaces into the use cases that create donations and memberships. Call the new method *after* the entity was persisted.