Permission dropdown allows mismatched account-type / permission-type combinations #15

New issue

Open

opened 2026-05-16 21:06:13 +00:00 by padreug · 0 comments

padreug commented

2026-05-16 21:06:13 +00:00

Owner

Summary

In both the "Grant Account Permission" (user-level) and "Add Permission to Role" (role-level) dialogs, the Permission Type dropdown offers every type regardless of the selected account's type. The backend silently accepts the grant, but the entry-submission endpoints never honor it — leading to confusing 403s.

Concrete cases:

Granting Submit Expense on a Revenue account (e.g. Income:Accommodation:Guests) — useless: /entries/expense checks against an expense account, never against this one.
Granting Submit Income on an Expense account — useless: /entries/income requires the account to be AccountType.REVENUE.
Granting either on an Asset/Liability/Equity account — useless: only Expense/Revenue accounts are meaningful targets.

This came up while wiring up #9 — an existing role had Submit Expense granted on an Income account, the admin assumed it would cover income submission, and the user got a 403 with no obvious diagnostic.

Proposed Fix

In static/js/permissions.js / templates/libra/permissions.html, filter the Permission Type options based on the currently selected account's account_type:

Asset / Liability / Equity → Read, Manage only.
Expense → Read, Submit Expense, Manage.
Revenue → Read, Submit Income, Manage.

The filter should reactively update when the account selection changes, and should reset the permission_type field if the current selection becomes invalid for the new account.

Severity

UX / footgun. No data corruption, but actively misleading for admins setting up role-based access and a frequent cause of the user-visible "you do not have permission..." 403.

## Summary In both the "Grant Account Permission" (user-level) and "Add Permission to Role" (role-level) dialogs, the Permission Type dropdown offers every type regardless of the selected account's type. The backend silently accepts the grant, but the entry-submission endpoints never honor it — leading to confusing 403s. Concrete cases: - Granting `Submit Expense` on a Revenue account (e.g. `Income:Accommodation:Guests`) — useless: `/entries/expense` checks against an expense account, never against this one. - Granting `Submit Income` on an Expense account — useless: `/entries/income` requires the account to be `AccountType.REVENUE`. - Granting either on an Asset/Liability/Equity account — useless: only Expense/Revenue accounts are meaningful targets. This came up while wiring up #9 — an existing role had `Submit Expense` granted on an Income account, the admin assumed it would cover income submission, and the user got a 403 with no obvious diagnostic. ## Proposed Fix In `static/js/permissions.js` / `templates/libra/permissions.html`, filter the Permission Type options based on the currently selected account's `account_type`: - Asset / Liability / Equity → `Read`, `Manage` only. - Expense → `Read`, `Submit Expense`, `Manage`. - Revenue → `Read`, `Submit Income`, `Manage`. The filter should reactively update when the account selection changes, and should reset the `permission_type` field if the current selection becomes invalid for the new account. ## Severity UX / footgun. No data corruption, but actively misleading for admins setting up role-based access and a frequent cause of the user-visible "you do not have permission..." 403.

padreug referenced this issue

2026-05-18 21:44:36 +00:00

Add user-facing asset purchase entry (parallel to expense/income) #20

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

aiolabs/libra#15

No description provided.

Rows
Columns