Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API: reconciled: false does not have precedence #8893

Closed
4 tasks done
dreautall opened this issue May 17, 2024 · 4 comments
Closed
4 tasks done

API: reconciled: false does not have precedence #8893

dreautall opened this issue May 17, 2024 · 4 comments
Labels
bug Verified and replicated bugs and issues. fixed Bugs that are fixed (in a coming release).

Comments

@dreautall
Copy link

Support guidelines

I've found a bug and checked that ...

Description

Dealing with changes to reconciled transactions using the API is a bit unexpected.

When editing a reconciled transaction via PUT api/v1/transactions/1234, as soon as the request has any "protected" field the API call will fail with an error that the transaction is reconciled. This is true even when reconciled: false is submitted in the request, or if the "protected" field value is not changed.

Debug information

Demo Page

Expected behaviour

  1. When the request contains reconciled: false, it should un-reconcile the transaction and then proceed any changes made in the same request. Currently, a reocnciled: false request is needed, followed by a separate request to actually update any fields.
  2. Even for reconciled transactions, if the request contains "restricted" fields such as amount, but that field is not changed compared to the stored value, the request should not fail but proceed to update any other fields if applicable.

Steps to reproduce

No response

Additional info

Looking at the web page, all fields seem to be filtered out of the update request when the transaction is reconciled to not fail according to the second point above. If this is the way you intend it to be, then consider this request only for the first point above (as this is quite annoying), and I'll implement something similar like the web page in the app!

@JC5
Copy link
Member

JC5 commented May 17, 2024

I'll check it out, thanks!

@JC5 JC5 added the triage Still checking this out... label May 17, 2024
Copy link
Contributor

Hi there!

This is an automatic reply. Share and enjoy

This issue has been marked as being in triage. The root cause is not known yet, or the issue needs more investigation. You can help by sharing debug information (from /debug) if you also have this issue or when you haven't already done so.

Thank you for your contributions.

@JC5
Copy link
Member

JC5 commented Jun 15, 2024

Assuming you want to update protected fields.

  • If you submit "reconciled": true to any unreconciled transaction, that will be the last time you can edit it. After that, it will complain.
  • Submitting "reconciled": false allows you to overrule this, and your updates will be saved. The transaction will be unreconciled as well.
  • Even if you leave the value the same, Firefly III will complain about trying to update reconciled transactions. The validator can't check existing values, i have enough spaghetti code as it is.

@JC5 JC5 added bug Verified and replicated bugs and issues. fixed Bugs that are fixed (in a coming release). and removed triage Still checking this out... labels Jun 15, 2024
@JC5 JC5 added this to the firefly-iii-v6.1.17 milestone Jun 15, 2024
@dreautall
Copy link
Author

Even if you leave the value the same, Firefly III will complain about trying to update reconciled transactions. The validator can't check existing values, i have enough spaghetti code as it is.

Alright thank you, I'll add some code for this case in my app then to not re-submit unmodified values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Verified and replicated bugs and issues. fixed Bugs that are fixed (in a coming release).
Projects
Status: Done
Development

No branches or pull requests

2 participants