Add user-facing income/revenue submission endpoint #13
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feature/income-submission-endpoint"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
POST /api/v1/entries/incomeendpoint mirroring the expense flow: invoice-key auth, pending!flag, reuses the existing/entries/{id}/approveand/rejectendpoints (which match bylibra-{id}link, entry-type-agnostic).PermissionType.SUBMIT_INCOMEgranted on revenue accounts — kept distinct fromSUBMIT_EXPENSEso admins can grant the two independently.AccountType.REVENUEon the income account andAccountType.ASSETon the payment-method account; fiat currency is required.Closes #9
Test plan
SUBMIT_INCOMEto a non-admin user on anIncome:*account; submit viaPOST /libra/api/v1/entries/incomewith invoice key — entry appears in Fava with!flag and#income-entrytag.GET /libra/api/v1/entries/pendingalongside pending expenses.POST /libra/api/v1/entries/{id}/approve— Beancount source flag flips!→*and balances update.POST /libra/api/v1/entries/{id}/reject— entry gets#voidedtag and is excluded from balances.SUBMIT_INCOMEpermission returns 403 with a clear error.currencyreturns a Pydantic validation error.🤖 Generated with Claude Code
Mirrors the existing expense submission flow so non-admin users can log income on behalf of the organization for super-user review. New endpoint POST /api/v1/entries/income takes invoice-key auth, creates a Beancount transaction with the pending '!' flag, and reuses the existing /entries/{id}/approve and /reject endpoints (which match by libra-{id} link regardless of entry type). Adds PermissionType.SUBMIT_INCOME granted on revenue accounts (parallel to SUBMIT_EXPENSE on expense accounts) rather than overloading SUBMIT_EXPENSE — the two operations target distinct account types and should be grantable independently. Enforces AccountType.REVENUE on the income account and AccountType.ASSET on the payment-method account; fiat currency is required (matches the expense flow's effective requirement). Income entries get a 'income-entry' tag and an ^inc-{entry_id} link for tracking, and surface in the existing /entries/pending list for super-user approval. UI work lives in the standalone webapp, out of scope here. Closes #9 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>When a user submits income, the money is physically in *their* pocket, not the entity's cash drawer. The original income endpoint posted DR on a configurable payment-method asset account (Cash/Bank/Lightning), which implicitly assumed the entity already had the funds. Mirror the expense flow instead: DR Assets:Receivable:User-{id[:8]} (via get_or_create_user_account), CR the revenue account. The user now owes the entity until they hand the cash over via the existing /settle-receivable workflow. With this, the per-user Outstanding Balances card correctly nets expenses (entity owes user, -liability) against income receipts (user owes entity, +receivable). Drops payment_method_account from IncomeEntry — no longer needed.@narayan got it working!
However, the plot thickens!
If
User Aaccepts income from anotherUser Bwithin the system, then the otherUser Bhas settled that amount of debt with the organization and theUser Ahas assumed it!I suppose there could be, when adding an Income, an option to choose a user within the organization they received from.
Might need to walk through that one with you 😆