ihatemoney
ihatemoney copied to clipboard
spiral-project
Split bill by amount or percentage.
Certain applications like Kittysplit and GroupTabs allow for splitting a bill unequally. This is useful in situations like a restaurant where one person may pay for multiple people's meals.
This can be emulated by separate bills for each check, but really the bills should be grouped together logically and the alternative is tedious.
Hi, thanks for opening a discussion here !
Do you have a copy of the UX these projects use to accomplish this?
Okay, thanks for the info. I wonder if we want to do this, I fear it will clutter a bit the UI. What do other involved contributors think ? (cc @eMerzh @0livd @JocelynDelalande)
I would clearly not do this by default (like not in the main path...) But maybe behind an advance option or smth....
UI-wise : for that king of needs, on the add bill popup, we could have two tabs :
- « simple » with what we have now
- « advanced » with the kind of new stuff we are discussion, for example.
note: it would have to play nice with user weights.
The impact on db would be quite important also.
The impact on db would be quite important also.
For me, this is one of the main aspects we should consider. Supporting this scenario means that the API will change quite a bit, and I'm a bit reluctant to this.
Also, UI-wise, IHM always has been as simple as can be, and I believe it's the wise path. Any other input would be useful :-)
I'm mostly leaning towards the "we should not go that way", because it seems to be a complex use case that I'm not sure will be useful to the vast majority of users.
So unless we have other inputs, I'm thinking about rejecting the idea.
I'm surprised this is considered a complex and rare use case. In my experience, the vast majority of expenses need to be split in a personalized way. The lack of this feature in open source/free solutions is why some people (including me) are stuck with Tricount. I strongly encourage to consider this feature.
@2lafru To be honest, I had the use case a couple days ago where we had to split a restaurant bill and one person haven't had drinks.
The way I did it was to create two bills:
- 1 bill paid by the person with the amount for the 1 person
- 1 bill with the rest of the amount paid by the same person with the amount share between the remaining people.
I think we could have a wizard that allow to create a split bills with custom amount per people and then create multiple bills accordingly, those we could keep the API simple and handle this use case for some people.
I'm surprised this is considered a complex and rare use case
It's my experience : I've been using the app since its conception and i never did miss this feature, so considering this as an "urgent" use case or something that we should "absolutely" doesn't seem right.
That being said, allowing this use case via a different UI might be acceptable. We should take extra care about not making the UX more complex that it already is.
I plan on implementing this feature. The first step is to refactor the code so that the api can diverge. Please approve pull request: https://github.com/spiral-project/ihatemoney/pull/533
The first step is to refactor the code so that the api can diverge.
I am really curious on this :)
@Glandos @almet @Natim @2lafru Getting closer to having this feature implemented. In the project settings you'll be able to set "advanced weighting" to enabled. The front end gui is working and additional database queries have been added. I'm having issues with retrieving the data (weights) from the submitted form. My attempts at using FieldList(FormField(ForWhomForm) for the "For Whom?" section haven't been successful.
If you guys would like to make an attempt the tree I'm working on is here: https://github.com/DavidRThrashJr/ihatemoney/tree/split_bills
New additional weight fields in the add bill screen. Amount due changes dynamically, when the weights are changed.
Settings screen:
@DavidRThrashJr I have created a demo project with 2 participants and 1 bill. Then switch to your branch, and I got this:
sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) no such column: billowers_1.ower_id
[SQL: SELECT person.id AS person_id, person.project_id AS person_project_id, person.name AS person_name, person.weight AS person_weight, person.activated AS person_activated, anon_1.bill_id AS anon_1_bill_id
FROM (SELECT bill.id AS bill_id
FROM bill JOIN person ON person.id = bill.payer_id JOIN project ON project.id = person.project_id
WHERE bill.payer_id = person.id AND person.project_id = project.id AND project.id = ? ORDER BY bill.date DESC, bill.creation_date DESC, bill.id DESC
LIMIT ? OFFSET ?) AS anon_1 JOIN billowers AS billowers_1 ON anon_1.bill_id = billowers_1.bill_id JOIN person ON person.id = billowers_1.ower_id ORDER BY anon_1.bill_id]
[parameters: ('demo', 100, 0)]
(Background on this error at: http://sqlalche.me/e/e3q8)
I don't know how you managed to reach your screenshot.
Hi, as I was looking for a self-hosted tricount alternative, I found out about this project,
not being able to distribute a bill unevenly almost ruled it out for me (and luckily I dug up this issue).
UI doesn't have to be sacrificed either, here is how it looks in tricount, which is pretty much what @JocelynDelalande proposes.
Thanks @DavidRThrashJr for pushing this :)
That's great :-) @DavidRThrashJr I've checked out your latests commits, but didn't manage to reach a usable state either.
Here is what I have currently 
@DavidRThrashJr are you okay opening a pull request here indicating "WIP" in its title, so we can follow your progress? Cheers!
The UI is not the only thing, but clearly, the Tricount design shows that it is easier for a user to enter an amount instead of a weight.
@Glandos The weights just need to equal the amount, if you want to enter direct amounts.
@indatwood you have to go to the project settings to enable the advanced amounts We may implement it like triccount eventually
I've copied the triccount layout, except you can't specify the amount per person in the due column. You have to use the weight column.
The advanced toggle switch is enabled for all projects. You can set the project to be in the advanced mode by default, for those who always use the advanced mode it saves a button press.
Please note that currently, you can specify the weights for each person at the project level.
It doesn't make sense to have weights at the project level and the bill level.
My proposal is to allow users to still be able to set the weights for each person at the project level. What will happen is, if the weights for each person at the project level is not set to 1 (default). Then when creating a new bill, the form will automatically populate with the weights that are set at the project level.
@Glandos @indatwood @almet What do you guys think?
My proposal is to allow users to still be able to set the weights for each person at the project level. What will happen is, if the weights for each person at the project level is not set to 1 (default). Then when creating a new bill, the form will automatically populate with the weights that are set at the project level.
I'm currently using weights for a full project, so I'll be glad if it's still working. What I don't understand here is: what happens if weights are changed when creating a bill? Will it change weights on the project?
I'm currently using weights for a full project, so I'll be glad if it's still working.
There wouldn't be a clean transition to what I proposed. The function to calculate what is owed won't use the project level weights anymore. Only the weights on the bill level will be used to calculate what is owed. I could write a transition script to set the bill level to be what is set at the project level during the upgrade to the new version.
What I don't understand here is: what happens if weights are changed when creating a bill? Will it change weights on the project?
No it would not change those weights. If the user wants to modify the "default" weight they would have to go back to the project level settings and modify the setting there.
The easiest solution would be to only have the advanced toggle switch show up if the user wants the advanced mode. Basically you get one or the other you can't have both project level weights and bill level weights.
Thanks for working on this :-)
At first, I found it weird to use weights rather than direct amounts, but I now understand this is due to the naming. Especially if we are using weights on the project, then I think we shouldn't name the two concepts the same way.
What about percentage? I think it betters explains what it does. Also, would it be complicated to add the direct amounts?
There wouldn't be a clean transition to what I proposed.
@DavidRThrashJr Both weighting mechanisms could be used in combination to ease the transition, I think it's fine as long as it's clear what the effect is:
| user | weight¹ | user weight²³ | effective weight³ | due |
|---|---|---|---|---|
| persona | 300 | 2 | 600 | 362 |
| personb | 156 | 1 | 156 | 94 |
¹ editable in the bill form ² read-only in the bill form, editable in project conf ³ only shown when per-user weights are used
I even think it's even preferable like this, because the calculations are everywhere consistent (and not dependent on set preferences).
@indatwood : what do you do with/how do you name "percentages" whose sum isn't bound to equal 100?
Both weighting mechanisms could be used in combination to ease the transition, I think it's fine as long as it's clear what the effect is:
Too complicated, this didn't pass the "wife usability check"
I'm ok, with making the advanced mode unavailable for people who want to use the weighting on the project level. I just need confirmation from the maintainers of this repo that they'll approve a merge request if it is designed this way.
@DavidRThrashJr if both approaches can't play together/at the same time, doesn't it also mean giving up on backwards compatibility for existing projects?
Correct. The best case scenario for the existing projects is as follows: When we run the migration.py to the new database schema that includes the weight column in the billowers table, we set the weight in that table to the current project level weights. After that point, the add bill form will pre-populate with the project level weights, thus allowing both project level weights and bill level weights to co-exist.