Implements a "Settle Receivable" feature for super users to record manual payments from users who owe money.
Introduces a dialog for inputting payment details (amount, method, description, reference), triggers an API call to record the transaction, and updates user balances and transaction history.
This is for non-lightning payments like cash, bank transfers, or checks.
Moves the "Quick Actions" card to the top of the dashboard for better user accessibility and discoverability.
Removes the duplicate card at the bottom.
Refactors the accounting logic into a clean, testable core module, separating business logic from database operations.
This improves code quality, maintainability, and testability by creating a dedicated `core/` module, implementing `CastleInventory` for position tracking, moving balance calculations to `core/balance.py`, and adding comprehensive validation in `core/validation.py`.
Implements balance assertions, reconciliation API endpoints, a reconciliation UI dashboard, and automated daily balance checks.
This provides comprehensive reconciliation tools to ensure accounting accuracy and catch discrepancies early.
Updates roadmap to mark Phase 2 as complete.
Improves balance assertion creation by handling Decimal types correctly for database insertion.
It also fixes a validation issue in the UI where the expected balance was not correctly validated as a required field and initializes the value to 0.
Adds balance assertion functionality to enable admins to verify accounting accuracy.
This includes:
- A new `balance_assertions` table in the database
- CRUD operations for balance assertions (create, get, list, check, delete)
- API endpoints for managing balance assertions (admin only)
- UI elements for creating, viewing, and re-checking assertions
Also, reorders the implementation roadmap in the documentation to reflect better the dependencies between phases.
Ensures that only cleared entry lines are included when
calculating fiat balances by filtering based on the
journal entry's flag. Excludes pending, flagged, and
voided entries
Adds an admin approval workflow for user-submitted expenses. This ensures that only valid expenses affect user balances.
The workflow includes pending expense states, admin approval/rejection actions, balance filtering, and UI updates.
Implements expense approval functionality, allowing superusers to review and approve or reject expense entries.
This includes:
- Filtering account balance calculations and user balance calculations to only include cleared journal entries.
- Adding API endpoints to retrieve pending expense entries and approve/reject them.
- Updating the UI to display pending expenses to superusers and provide actions to approve or reject them.
This ensures better control over expenses within the system.
Marks Phase 1 as complete in the documentation.
Updates the transaction list in the UI to display transaction status flags and metadata, enhancing user understanding of each transaction.
Implements core improvements from Phase 1 of the Beancount patterns adoption:
- Uses Decimal for fiat amounts to prevent floating point errors
- Adds a meta field to journal entries for a full audit trail
- Adds a flag field to journal entries for transaction status
- Migrates existing account names to a hierarchical format
This commit introduces a database migration to add the `flag` and `meta` columns to the `journal_entries` table. It also includes updates to the models, CRUD operations, and API endpoints to handle the new fields.
Provides detailed documentation for the Castle Accounting extension, including architecture, transaction flows, balance calculation, API endpoints, and future improvements.
Documents design patterns inspired by Beancount, such as immutable data structures, plugin architecture, and balance assertions, with recommendations for adoption in the Castle extension.
Includes an implementation roadmap, security considerations, performance considerations, and a migration path for existing data.
Improves clarity by displaying "Payable" or "Receivable" badges on entries
in the transaction list.
The badge color depends on whether the user is a superuser, indicating
the direction of the transaction from the user's perspective.
This helps users quickly understand which transactions are owed to them
and which they owe.
Improves the display of user balances in the admin panel by including the username alongside the user ID. This provides a more user-friendly and easily identifiable representation of user data.
The username is fetched from the user table, and if no username is set the first 16 characters of the user id is shown.
Ensures that account creation utilizes the user ID
associated with the wallet, rather than directly
relying on the wallet identifier. This aligns account
ownership more accurately.
Ensures that only the super user can access and modify manual payment requests via the admin API endpoints. This enhances security by preventing unauthorized access to sensitive administrative functions.
Removes dependency on `check_super_user` helper function, instead directly comparing the wallet user with the configured super user in lnbits settings.
Renames database migration functions to correct a numbering error.
The original migration `m002_add_metadata_column` was removed in a previous commit,
but the subsequent migrations were not renamed to reflect this, leading to
incorrect numbering. This change corrects the function names to ensure
proper sequential execution during database migrations.
Enables users to request manual payments from the Castle and provides admin functions to approve or reject these requests.
Introduces the `manual_payment_requests` table and related CRUD operations.
Adds API endpoints for creating, retrieving, approving, and rejecting manual payment requests.
Updates the UI to allow users to request payments and for admins to review pending requests.
For super users, the balance view now displays the net position
(liabilities - receivables) of the Castle. The journal view
shows all entries across all users.
The settings are now loaded first to determine if the user is a
super user.
Improves user experience by visually indicating entries that represent outstanding payments owed by users.
This change introduces a "Pending Payment" badge for receivable entries in the transaction list. A receivable entry is determined by checking if the entry contains a debit line item against an account receivable account. This provides immediate visual feedback to the user, highlighting transactions requiring their action.
Updates journal entry retrieval to filter entries based on
the user's accounts rather than the user ID.
This ensures that users only see journal entries that
directly affect their accounts.
Also displays fiat amount in journal entries if available in
the metadata.
Extends user balance information to include fiat currency balances,
calculated based on entry line metadata and account types.
This allows for a more comprehensive view of user balances,
including both satoshi and fiat currency holdings.
Updates the castle index template and API to display fiat balances.
Improves the reliability of payment status updates by ensuring that the payment polling interval is properly cleared when a payment dialog is closed, when a payment is submitted, or when a new payment dialog is opened. This prevents multiple polling intervals from running simultaneously, which could lead to incorrect payment status updates.
Adds a watch to clear interval when the pay dialog closes.
Adds functionality for users to pay their Castle balance by generating and paying a Lightning invoice.
This includes:
- Adding API endpoints for invoice generation and payment recording.
- Updating the frontend to allow users to initiate the invoice payment process.
- Passing the wallet's `inkey` to the frontend for payment status checks.
Implements a feature that allows users to pay their outstanding balance via Lightning.
The changes include:
- Adds the UI elements for invoice generation and display, including QR code.
- Integrates backend endpoints to generate and record payments.
- Adds polling mechanism to track payments and update balance.
- Creates new database models to support manual payment requests.
Updates the receivable entry model and related API endpoints to use the user's ID instead of the user's wallet ID.
This change simplifies user identification and ensures consistency throughout the application.
Implements the ability to record receivables (user owes the castle).
Adds API endpoint for creating receivable entries, which includes currency conversion to satoshis if fiat currency is provided.
Integrates a UI component (receivable dialog) for superusers to record debts owed by users, enhancing financial tracking capabilities.
Implements functionality for super users to view a breakdown of outstanding balances for all users.
This includes:
- Adding an API endpoint to fetch all user balances.
- Updating the frontend to display these balances in a table, accessible only to super users.
- Modifying the balance calculation for the current user to reflect the total owed by or to the castle for super users.
This provides super users with a comprehensive view of the castle's financial position.
Simplifies the user experience for super users by automatically using the Castle wallet for transactions, removing the need to configure a separate user wallet.
This change streamlines the workflow for super users by:
- Automatically assigning the Castle wallet to super users
- Hiding the user wallet configuration options in the UI
- Reloading user wallet settings to reflect the Castle wallet
Updates the castle wallet ID input to a select field populated with available wallet options.
This change improves usability by providing a predefined list of wallet options.
It also disables the save button if no wallet is selected.
Allows users to configure their own wallet ID, enabling
the system to track expenses and receivables on a per-user basis.
Introduces new database table, models, API endpoints, and UI elements
to manage user-specific wallet settings.
Adds super user role to restrict settings changes.
Improves the settings screen to only allow super users to make modifications.
Adds a warning banner if the Castle wallet is not configured.
Changes admin key to inkey for fetching settings.
This fixes an issue where settings weren't accessible.
Adds a validation to require the Castle wallet ID when updating settings.
Adds functionality to configure the Castle extension, including a wallet ID.
This allows administrators to customize the extension's behavior by specifying a dedicated wallet for castle operations.
Adds a metadata column to the entry_lines table.
This column will store currency conversion data as JSON, allowing for future flexibility in handling different types of metadata.
Updates journal entry creation to store entry line metadata as a JSON string in the database.
Updates entry line retrieval to parse the JSON string back into a metadata object.
This change allows storing more complex data structures in the metadata field.
Removes redundant "/api/v1" prefixes from API router definitions in the backend and updates the corresponding API calls in the frontend. This change streamlines the API structure and improves code maintainability. Additionally, adds console logs in the frontend to aid in debugging the API calls.
Extends expense entry functionality to support fiat currencies.
Users can now specify a currency (e.g., EUR, USD) when creating expense entries. The specified amount is converted to satoshis using exchange rates. The converted amount and currency information are stored in the journal entry metadata. Also adds an API endpoint to retrieve allowed currencies and updates the UI to allow currency selection when creating expense entries.
Improves the UI of the "Add Expense" and "Pay Balance" dialogs by using `q-input` and `q-select` components with `filled` and `dense` properties.
This provides a cleaner and more modern look and feel.
Ensures dialog content is only rendered when the dialog is visible.
Removes the `castle.` prefix from database table names in queries, streamlining data access.
Updates authentication to use `WalletTypeInfo` dependency injection for retrieving wallet information. This improves security and aligns with LNBits' authentication patterns. Also modifies the main router's tag to uppercase.
Removes the "castle." schema prefix from database table creation and index definitions in the migration file.
This change enhances database portability by allowing the application to function correctly with different database configurations.
