-
Notifications
You must be signed in to change notification settings - Fork 271
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
Currencies: rework or remove? #1232
Comments
I agree we should stop relying on an external service. Your solution is probably the most reasonable but is still a bit complex. Let me try to widen the discussion by proposing more radical alternatives:
In any case, let's keep in mind the original use-case: handling bills in multiple currencies in a single project. For reference, here are the original discussion and pull request: |
I actually would advocate for removing currencies all together. I'm not using this feature so I might be too optimistic, but I actually believe it's part of the features that we should have rejected at first to keep the codebase simple. |
See #1232 for a discussion on currencies
See #1232 for a discussion on currencies
* hotfix: hardcode list of currencies to workaround failing API calls See #1232 for a discussion on currencies * Temporarily disable some currency operations to prevent crashes Here is what is disabled: - setting or changing the default currency on an existing project - adding or editing a bill with a currency that differs from the default currency of the project --------- Co-authored-by: Baptiste Jonglez <git@bitsofnetworks.org>
As a British person living in The Netherlands with a Swiss partner I find the multiple currencies super useful! So I would definitely advocate for keeping it in haha. Found this issue cause my ihatemoney project has fully stopped working. Although yeah I generally do not really like the automatic currency conversion and would actually prefer just having the currencies separate. I generally have some of each currency in my Revolut/Wise/whatever at the same time, so sometimes settle up in other currencies. Or, when I do decide to settle it all up in euros or something, I just check the current exchange rate that's available to me and take that, so I don't really use the rate that ihatemoney is using anyway. I guess the downside here is settling the bill could be a bit clunky. e.g. if I owed my partner 80 CHF and she owed me 100 EUR, settling the bill wouldn't be able to be reduced to a single transaction. But still, the maximum amount of different transactions you would have to do is one per currency. I think generally the number of different currencies would be 2 or 3, so it would still be fairly simple maths. Ideally you could then have the option to manually put in some exchange rates that you and the other members agree on when settling the bill would be nice - but I would say this could be in the next iteration. I would say hitting an API for automatic exchange rates is overkill for a FOSS project and manually inputting them is fine. |
Since the external service stopped working my project stopped working as well. On my MoneyBuster app on Android when updating my project or when adding a new item to my project I get the error "Project-Sync failed" with the following description: "Syncing the project failed. Error message: I also can not add new bills on ihatemoney itself. When hitting the "Submit" button nothing happens. I saw in my ihatemoney account that I can not choose any default currency (see screenshot below). This might the problem? I would really like to see the new feature but I would appreciate it more if the service would work again :-) |
I also think that supporting multiple currencies is crucial. Coming from Tricount, I always used this feature as my main use case is splitting money with other people while traveling. At least for this use case, fixed (but adjustable) rates would be perfectly fine. For longer projects where the rate can change significantly, it would be useful to have the exchange rate per entry, so your suggestion @almet would work. I think, however, that it is crucial, that the original value with the associated currency, needs to be stored and also displayed, as in my experience this is the thing you check if you want to see if an entry is correctly entered. The converted values should only be shown for information and then used for settling. |
Adding some input from #1263, apparently Splitwise uses the third approach I described (also explained in more details by @dylanmorroll above). They simply consider each currency separately when settling. It seems the most sensible approach to me, maybe with the addition of a manual conversion whenever needed. |
+1 love for the currency conversion feature. We're a group of people that exclusively use ihatemoney for travel, so it's super useful. |
hello,
|
* hotfix: hardcode list of currencies to workaround failing API calls See spiral-project#1232 for a discussion on currencies * Temporarily disable some currency operations to prevent crashes Here is what is disabled: - setting or changing the default currency on an existing project - adding or editing a bill with a currency that differs from the default currency of the project --------- Co-authored-by: Baptiste Jonglez <git@bitsofnetworks.org>
there is this open API https://github.com/fawazahmed0/exchange-api |
After a discussion with @zorun, we're leaning towards keeping the support of multiple currencies, with conversion rates fixed in the per-project settings, with potentially some fixed rates in the code. It's worth noting that we don't want to write this code ourselves (because we don't need it ourselves). We would gladly accept contributions on the matter, which we would review though. In order to go forward on the matter, we are letting this task open to take for any volunteer for the next 6 month. If you want to code this, don't hesitate to chime in! Passed October the 31th (of 2024), in the eventuality nobody implemented it, we would delete the feature all together. |
Almost too late - would something like this be worth finishing? |
For more information about the rationale, this was [discussed](#1232 (comment)) in our bugtracker.
For more information about the rationale, this was [discussed](#1232 (comment)) in our bugtracker.
For more information about the rationale, this was [discussed](#1232 (comment)) in our bugtracker.
For more information about the rationale, this was [discussed](#1232 (comment)) in our bugtracker.
We currently use an external API to get conversion rates, and it went away. I think we should not rely on external services anymore to do these kind of tasks.
My proposal is to :
Would that be okay for you? (cc @Glandos as git blame points to you on this code / last changes).
Cheers :-)
The text was updated successfully, but these errors were encountered: