rule action to link transactions with certain tag

[hamuz]

Description
Please describe your feature request:

• I would like Firefly III to link a transaction with different transaction automatically.

Use case: I want to link credit card transactions to their payment, when a rule triggered on the payment.
Assumptions: the transactions to be linked are tagged beforehand (for example, "current month") - maybe even using another rule (not the focus of this issue).
It would be useful to remove/replace that tag after linking.

Solution
Describe what your feature would add to Firefly III.

1. "Trigger other rule" action - would provide the most flexibility

• choosing on which transactions (cc transactions, for example) to trigger (having tag, having source account, etc.)
• choosing what to do which matched transactions (remove tag, add tag)
• needs new action - "create new link with triggering transaction" (transfer bank -> cc)
  or

2. "link transactions with certain tag" - just specify the link and the tag.

What are alternatives?
Please describe what alternatives currently exist.

manually going to each transaction and linking to transfer.

[JC5]

I'm sorry, this is way too complex. I understand your use case of course but it's really something else to automate this from within Firefly III.

Rules triggering other rules is a smart way of selecting a source transaction. You've effectively turned it into a search engine. Another rule would take that search result and act on it.

But this would also require a complete rewrite of the rules engine, in order for them to be aware of "input" from previous rules (which could be a chain) adding all sorts of complexities.

It's impossible to turn this into a user friendly system that new people would get. The current rule engine is already crossing the line here.

I would suggest you build something that acts on the database directly. You can use the API if you want to.

[hamuz]

How about adding webhook action? POSTing matched transaction json object.

[JC5]

I'm not going to implement webhooks for one use case. You've got yourself an edge case and I can't help you with it I'm afraid.

[hamuz]

What if I implement it? Your API users might find it useful... It complements the API.
Similar to how Github webhooks complement the Github API.

[JC5]

No. There’s plenty of technical debt already.

[hamuz]

I've sent pull request for some initial implementation in #1757 .
Tested against Huginn.
Maybe in the future it will be tested against Zappier.

[hamuz]

No. There’s plenty of technical debt already.

What exactly do you mean by that?

[JC5]

Yes, I saw your question.

There's a lot of technical debt surrounding stuff that barely anybody uses. I'm not going to add another package and a bunch of code in order to be able to push transaction information to external sites. Feel free to merge it into a fork of Firefly III, that's the beauty of open source software, but I'm not going to merge it into the master branch.

[hamuz]

This package was is already present in the vendor folder.
It's a dependency for many of FireFly dependencies, like:

1. Bunq PHP SDK
2. Laravel passport
3. PHP coveralls (although it's dev dependency).

So you're not adding anything not already there.

Would tests and documentation for this would help reduce the technical debt?
Also a step-by-step guide, how to implement that bank->cc use case using Huginn (like FireFly - self-hosted zappier/ifttt - so no outside sites receiving transactions) and the new webhook?

This would help the user base with automating a common (in my opinion) use-case, and would provide benefits of using existing features of FireFly (like rules, links, and the API) to its fullest.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[hamuz]

I'm a bit sad I have to manage separate fork for the project only because of the webhook action.

It is a good mechanism in my opinion to notify external systems of events (like specific type of transaction imported) to kick of various use cases ranging from enriching the transaction with attachments (automatically) or linking it to other transactions, as previously detailed.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.