-
Notifications
You must be signed in to change notification settings - Fork 147
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
1008 ideal integration online payment provider #1031
1008 ideal integration online payment provider #1031
Conversation
685552a
to
cda0f4b
Compare
cda0f4b
to
70944a7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, great to see this coming back, now properly as a core Foodsoft plugin! :)
It's been a long time, probably some questions I'm asking are about pieces you've just copied from the original code. Nevertheless, it's good to remain critical (also on my past self).
There are two possibly important assumptions that change:
- A FinancialTransaction's
amount
may benil
- A FinancialTransaction is mutable
This is something important to think through. Solid accounting has no changing history, but in this case we make an exception. I think this is justified, but I'm not 100% sure - both in Foodsoft core (not all parts of the code are tested fully), and by plugins/integrations people have written. This even affects the API (financial transations), where software using it may not expect nil
for amount.
I think before this PR is merged, someone needs to have a good look at this. Perhaps you've done that already.
Do we need to make a new API version for this, hide the unfinished transactions by default, or accept a possibly incompatible change (the API is relatively young, so maybe ok)?
One way to get an answer to this is to ask this question on the forum and/or Github.
I also asked some questions to which I could have found the answer myself. Hope that's ok, and you're patient enough to go look, think about it, and respond.
Some general things to improve could be (partly already mentioned in separate comments):
- Use strong parameters, they're standard now, and with finance-related code it's good to be safe.
- I think it's good to document what we expect from financial transactions, just some background in the main Foodsoft (I guess in-tree) developer docs, about the assumptions. Maybe it's not really a question for you. I think it would have best been done already with the introduction of financial transaction types and such. But this PR touches something quite important, so I think writing down something about financial transactions may help even getting your own mental model right.
Please feel free to disagree too, I hope we can have a constructive conversation :)
Thanks for all your work in making this ready for prime-time!
db/migrate/20230915093041_add_payment_to_financial_transaction.rb
Outdated
Show resolved
Hide resolved
plugins/mollie/app/overrides/admin/configs/_tab_others/add_config.html.haml.deface
Outdated
Show resolved
Hide resolved
p.s. if the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is shaping up nicely!
app/controllers/api/v1/user/financial_transactions_controller.rb
Outdated
Show resolved
Hide resolved
app/helpers/application_helper.rb
Outdated
if t.amount | ||
format_currency t.amount | ||
elsif t.payment_amount && t.payment_state | ||
content_tag :span, "#{number_to_currency t.payment_amount}) (#{t.payment_state})", class: :disabled_amount |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe even a title to explain that this is a transaction that is in progress, which may or may not be completed (but more concise maybe)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought it would be the best to just display the payment state as a seperate column. It felt weird to use the amount column for this information.
thx! your comment are very helpful :) |
1513b41
to
f777310
Compare
Hey I've been working a bit more an introduced some changes:
Hopefully I can finish up on this until end of this week :) |
f777310
to
4b846ae
Compare
Please let me know when it is ready for review (comment or the re-request review button), as it's been a while. Would be great to have this included in the next release. |
f711db6
to
ab8bd3a
Compare
hey @wvengen, thanks for the reminder. I know it's been a while ... I tried to write some documentation, though I don't feel very confident with it. I still don't understand very much of the banking feature. I see this docs as a starting point... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for working on this PR!
Some small comments, I think it would be almost ready for merging.
Super you added some documentation. I find the financial transaction types and such also not that easy to comprehend. I think it's mostly the Austrian foodcoops using this, so they can best provide input here. See also this forum thread, here is an issue showing a use-case, and this issue has also some background.
app/controllers/api/v1/user/financial_transactions_controller.rb
Outdated
Show resolved
Hide resolved
%th= heading_helper FinancialTransaction, :payment_method | ||
%th= heading_helper FinancialTransaction, :payment_amount | ||
%th= heading_helper FinancialTransaction, :payment_fee | ||
%th= heading_helper FinancialTransaction, :payment_state |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the table still readable with a number of added columns (with possibly long names)?
This is especially relevant for foodcoops not using a payment plugin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm maybe I can add a check if payment_plugin is not null and only display then? Or I could introduce another config setting that "enables" payments in general
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we don't need a config option, let's avoid it (as it's complex enough as it is). So if they're a straightforward way to derive this, yes. Looking at payment_plugin config seems sensible here, yes.
Could there be a situation where this information is still relevant but the payment plugin is disabled? E.g. a payment plugin was enabled, but now disabled? I think we can just hide it, because any payment-plugin-related things will fail anyway. But just checking. E.g. at some places we check if there's more than one financial transaction type, and only show certain things if there is (to avoid UI complexity when a feature is not used).
thanks for your feedback! I'll squash the commits later, I thought it could be easier for you to review like this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes! We're definitely getting there 🚀
Great you found the documentation, I didn't know about this, thanks for sharing.
%th= heading_helper FinancialTransaction, :payment_method | ||
%th= heading_helper FinancialTransaction, :payment_amount | ||
%th= heading_helper FinancialTransaction, :payment_fee | ||
%th= heading_helper FinancialTransaction, :payment_state |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we don't need a config option, let's avoid it (as it's complex enough as it is). So if they're a straightforward way to derive this, yes. Looking at payment_plugin config seems sensible here, yes.
Could there be a situation where this information is still relevant but the payment plugin is disabled? E.g. a payment plugin was enabled, but now disabled? I think we can just hide it, because any payment-plugin-related things will fail anyway. But just checking. E.g. at some places we check if there's more than one financial transaction type, and only show certain things if there is (to avoid UI complexity when a feature is not used).
067c424
to
18a889e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super! Some small notes, otherwise good to go, I think 🚀
app/views/finance/financial_transactions/_transactions.html.haml
Outdated
Show resolved
Hide resolved
18a889e
to
db46544
Compare
@wvengen let's merge? :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, and for a future PR, it's good to mention the issue number in the PR description (e.g. in this case "Implements #1008"), so that Github recognizes this and provides cross-references. The "1008" in the PR title didn't do this. |
…1008 , PR #1031) Co-authored-by: wvengen <[email protected]>
Co-authored-by: wvengen <[email protected]>
db46544
to
84998c3
Compare
Thank you for also keeping up and your helpful advise :) |
…1008 , PR #1031) Co-authored-by: wvengen <[email protected]>
Co-authored-by: wvengen <[email protected]>
This PR adds the online payment provider mollie as a plugin. User can add credit to their ordergroups balance via various payment methods. wvengen implemented this already in the foodsoft-adams fork. I rewrote some parts to make it work with the newest mollie api version and added some bits to improve the usability.
Changes relevant to the foodsoft core:
nil
now, this indicates an incomplete transactionChanges on the plugin:
still open
[ ] move accept_return_to to ApplicationController?