Support including private budget entries in account balance computation

[xyzarivera]

Use case: Me and my partner would like to our budget entries in private, but we would like to see the sum in the Accounts page so that we can see the actual account balances and net worth.

For example, I want to buy an expensive Overwatch skin, but Im embarrassed to show it. Currently, for this personal expense to reflect in the Accounts balance, it should be shared to the household. If we could allow private budget entries to be summed into the Account balance, then we can have a clearer, more accurate household net worth.

I have seen this comment and requests #476 and #505 to understand the current implementation.

I would also be happy contribute for this feature request
Thanks!

[ulsklyc]

Yes - and the way you framed it is what changed my mind, so let me be precise about what I took from it.

The current behaviour is deliberate. listAccounts filters other people's private entries out of both the balance and the entry count, because otherwise a shared account leaks them: watch the balance before and after, and you know the amount, and the entry count tells you something happened even when the amount is zero. That reasoning is sound and it stays.

But it answers a question you didn't ask. Your example is an expensive game skin - what's embarrassing is what it was for, not that €25 left the account. Today's model hides both, and that is exactly why your balance is wrong. Privacy of purpose and privacy of amount are two different things, and Yuvomi currently only has one word for them.

So the plan is a third visibility, per entry - something like "amount counts, purpose stays private". The entry contributes to the account balance and to net worth; its title, category and notes stay yours. You choose it per entry, the way you choose private or shared today.

What I deliberately did not do is add a household setting. That would have been much cheaper - one config value, private amounts count everywhere - and I rejected it for a specific reason: whoever flips it removes the guarantee for everyone in the household, including members who wanted it, and an admin could do that unilaterally. A privacy promise that a third party can switch off isn't one. Keeping the choice per entry means it stays with the person whose privacy it is.

Fair warning on size, since you offered to contribute: this is not a small change. The visibility filter runs through the whole Budget module and currently treats "counts towards sums" and "shows its details" as a single question. Splitting those two apart is the actual work - the migration on the CHECK constraint is the easy half. If you want to take it on, say so and I'll write up where the filter is applied and which call sites need to distinguish the two, so you're not reverse-engineering it from scratch.

[ulsklyc]

Released in v2.31.0.

It went in as described: a third visibility per entry, "amount only". The amount counts in the account balance, in net worth and in every total, while title, category, notes and receipts stay with you. Other members see the row with its date and its amount and a neutral placeholder where the title would be. Leaving the row out entirely would have been cheaper and it was the wrong call - the visible rows would then no longer add up to the balance above them, which reads as a bug rather than as a promise being kept.

The part that turned out to be bigger than the plan: splitting "counts towards sums" from "shows its details" was not one filter with a new value, it needed two filters that disagree. One answers does it count and treats the new level like shared. The other answers may I see what it was for and is as strict as private. Everything that aggregates by category needs the second one, because a correct total still leaks the purpose through its own breakdown - if your €25 lands under "Gaming" in the household's monthly summary, the placeholder on the row was pointless. The monthly summary and the statistics tab therefore file another member's amount-only entries into a neutral collecting bucket instead of their real category. The CSV export is masked for the same reason; otherwise it would be the most convenient way to read out exactly what the interface hides.

Two places where the level deliberately does not behave like shared:

• Inventory: an amount-only entry stays invisible, like private. A link between a booking and an object is a statement about what the money was for, and unlike a balance, nothing there adds up wrong when the booking is missing.
• Loans and subscriptions keep their two levels and act through the entries they generate. A value sent to them is rounded down to private, never up to shared.

No household setting, for the reason given above: whoever flips it removes the guarantee for everyone, including the members who wanted it.

On the offer to contribute - I ended up building it rather than leaving you to reverse-engineer the filter, since the two-filter split was the whole job and it touches every read path in the module. Thanks for the framing in the first place; the game-skin example is what made the distinction between hiding the amount and hiding the purpose obvious, and that distinction is the feature.