Transaction parsing sms gateway poc

[beesaferoot]

Makes progress on #1345

#1351 should be merged before this.

Brief summary of the change made

This PR expands on the bi-directional sms communication feature. With these changes we are creating use-case to support recording transactions from Mobile money providers through sms receipts.

MPM uses the sms gateway to obtain the receipts and does sms parsing using a flexible Parsing rule configured by the user as a plugin.

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]

Looks great. Leaving a few comments here.

1. Can you explain what is the exact purpose of MovitelTransactionParser and VodacomTransactionParser? For example, they simply get converted to Regex?
2. Is there a way, for each rule, to see the last X (maybe 15) messages that matched the filter? And, if they succesfully parsed?

[dmohns]

This part is essentially blocking users from adding any custom Parsing rules.

I'm trying to add a new Parsing Rule, but it only works if I use Vodacom or Movitel as a name.

[beesaferoot]

This has been updated.

[dmohns]

Could we make them specific to MZ?

[beesaferoot]

We no longer use this.

[beesaferoot]

1. Can you explain what is the exact purpose of MovitelTransactionParser and VodacomTransactionParser? For example, they simply get converted to Regex?

Originally the separation of MovitelTransactionParser and VodacomTransactionParser was to make parsing deserialization very flexible to updates, especially when updating the parsing rules.

However, with all the parsing rules having the same variables i.e txn ref, account, phone etc. I have now consolidated this into a single deserialization abstraction SmsTransactionParser. This make this simpler and eliminates bonding new parser rules manually to these classes.

Is there a way, for each rule, to see the last X (maybe 15) messages that matched the filter? And, if they succesfully parsed?

I think we can already get this information from the sms_transactions table, all that is needed is to hookup an page in the plugin that shows a paginated list for each parse rule (uniquely identified perhaphs by provider name)