Refactor: Unify transaction flow

[beesaferoot]

We previously duplicated transaction processing for Cash payments and "normal" transaction flow. This PR unifies them, thereby simplifying the overall flow.

Closes #1257

Brief summary of the change made

Are there any other side effects of this change that we should be aware of?

Describe how you tested your changes?

Pull Request checklist

Please confirm you have completed any of the necessary steps below.

• Meaningful Pull Request title and description
• Changes tested as described above
• Added appropriate documentation for the change.
• Created GitHub issues for any relevant followup/future enhancements if appropriate.

[dmohns]

Hey @beesaferoot

From what I understand, currently, when using CashTransactions. The Token that is generated has device_id = NULL. With your changes, the device_id get's populated. This is an intended side effect I assume?

We need to add a migration for this right? Note that the seeded data doesn't have this problem.

[beesaferoot]

Hey @beesaferoot

From what I understand, currently, when using CashTransactions. The Token that is generated has device_id = NULL. With your changes, the device_id get's populated. This is an intended side effect I assume?

We need to add a migration for this right? Note that the seeded data doesn't have this problem.

Didn't realize this side effect until you mentioned it, but yes, it is intended. I don't think we need a migration, the token is rightly tied to the right appliance (device) having the same result as previous cash processing logic.

[dmohns]

Didn't realize this side effect until you mentioned it, but yes, it is intended. I don't think we need a migration, the token is rightly tied to the right appliance (device) having the same result as previous cash processing logic.

I understand it's not strictly required. But I think I'd still like to have it. Else we will be in the situation where some (older) tokns don't have device_id and newer tokens have device_id. This will almost certain lead to problems in the future, no?

[beesaferoot]

Didn't realize this side effect until you mentioned it, but yes, it is intended. I don't think we need a migration, the token is rightly tied to the right appliance (device) having the same result as previous cash processing logic.

I understand it's not strictly required. But I think I'd still like to have it. Else we will be in the situation where some (older) tokns don't have device_id and newer tokens have device_id. This will almost certain lead to problems in the future, no?

With our use of Token with relation to transactions, I can't foresee issues entirely based on missing device_id. We can always get the device from the transaction that the token was generated by.

However, I could look into this to be on the safe side. To populate the missing device ids don't we need to still resort to the action above?

[beesaferoot]

Added a migration to backfill empty device ids on the Token table.

@dmohns