New group members can't be added to existing expenses.

[FriesischScott]

Currently, existing expenses can't be updated for new members when someone is added to the group. It would be great if the edit dialog included members that weren't present when the expense was originally created.

I don't think it should be too difficult to implement and would be happy to do it myself. I see two ways of doing this:

1. if a new member is added to a group all expenses in the database are updated to include them in the split without changing the existing distribution.
2. When editing an expense additional members not present in the split are loaded so they can be included in the updated expense

I prefer the first. I think it's quite clean.

@KMKoushik What do you think?

[ivandwijaya]

I suggest approach number 2. It's less disruptive, and I see a few potential issues with approach number 1:

• It will break settled expenses.
• It doesn't account for individuals who legitimately join the group late.
• With invite links, we have limited control over who joins the group, and any unexpected person joining could compromise the entire expense report.

[FriesischScott]

I have since opened a PR with approach 1 in #220.

Could you elaborate on the issues you see? All I am doing is adding new members to expenses as if they were already in the group but don't owe anything. I don't see it breaking any of the things you mentioned.

[krokosik]

What if we simply fetch all the group members by groupId, instead of showing expense participants in the edit dialog?

[krokosik]

@FriesischScott could you clarify?

[FriesischScott]

I think adding new members with 0 amount to existing expenses is probably the least invasive way to do it and requires no extra logic. By pretending the member was already in the group when the expense was created everything else can stay as is.

Through #179 the expenses would then show up nicely as Not involved.

Fetching the members missing from the expense and then using upsert to update or create the ExpenseParticipant rows should work as well but I think it's less clean.

[krokosik]

When you consider the database as the source of truth for the entire application, I do not see any sense in storing 0 balance expense participants in the DB, as it simply is useless information. What I see especially in bigger groups (on my instance) is that many expenses are cluttered with such balances, obscuring the view of actual participants.

What especially bothers me about approach number 1 is that you want to modify ALL expenses, which I consider unnecessary given the relative ease that the issue can be mitigated on the frontend. Anything that modifies the DB, especially so vastly, is not clean in my book.

I would much more lean towards solution number 2, where the frontend adds missing group members to the client store. We already have logic for changing participants (since you can change them in the split outside of a group) and when you look in the code, upsert of participants happens on every edit. I would like to make a refactor of the SQL/splitService logic for 1.5, but for now I would go with the simple frontend change in solution 2.

[FriesischScott]

As long as it's possible to add late members to expenses I'm happy. Andyou're right that it's unnecessary to crowd the database with zero rows.

Plus if we do decide to move forward with #247 it significantly reduces the number of rows to sum.

[krokosik]

Okay, I will go ahead with approach 2. Also, even without the refactor it might be good to exclude 0 amount expense participants. My concern is with friends. Should we remove individually added people with 0 balance from expenses? They can always be added again when editing the expense, while a group will have all group members filled automatically.