[GH-ISSUE #8400] [Bug] Inconsistent permission_id mapping between storage and access level #3799

New issue

Open

opened 2026-03-23 21:33:17 +00:00 by mirror · 0 comments

mirror commented

2026-03-23 21:33:17 +00:00

Owner

Originally created by @msljivic031 on GitHub (Dec 19, 2025).
Original GitHub issue: https://github.com/AppFlowy-IO/AppFlowy/issues/8400

Bug Description

I noticed a potential inconsistency in how permission_id is stored and later interpreted as access_level.

In workspace_shared_view_sql.rs, permission_id is persisted as an i32 and stored in the database.
Later, in manager.rs, this same field is converted into an access level enum.

However, the naming suggests permission_id is an identifier, while the runtime logic treats it as an access level value. This creates ambiguity between:

permission identity
permission semantics (actual access rights)

This could lead to subtle bugs if permission definitions change or if IDs are reordered or extended in the future.

Suggestion:
Clarify the model by either:

renaming permission_id to access_level consistently, or
introducing a proper permission mapping layer instead of casting raw integers.

How to Reproduce

This is a code-level design inconsistency and does not require a UI reproduction.

The issue can be observed by:

Inspecting workspace_shared_view_sql.rs where permission_id is stored as a raw i32 in the database.
Inspecting manager.rs where the same field is later interpreted and converted into an access level enum.

The mismatch becomes apparent by following the data flow between persistence and runtime interpretation.

Expected Behavior

The permission model should be unambiguous.

Either:

permission_id should represent a stable permission identifier with a clear mapping layer to access levels, or
the field should be consistently named and treated as access_level across storage and runtime logic.

This would improve clarity and reduce the risk of future permission-related bugs.

Operating System

Not OS-specific (code-level issue)

AppFlowy Version(s)

Current main branch

Screenshots

No response

Additional Context

No response

Originally created by @msljivic031 on GitHub (Dec 19, 2025). Original GitHub issue: https://github.com/AppFlowy-IO/AppFlowy/issues/8400 ### Bug Description I noticed a potential inconsistency in how permission_id is stored and later interpreted as access_level. In workspace_shared_view_sql.rs, permission_id is persisted as an i32 and stored in the database. Later, in manager.rs, this same field is converted into an access level enum. However, the naming suggests permission_id is an identifier, while the runtime logic treats it as an access level value. This creates ambiguity between: - permission identity - permission semantics (actual access rights) This could lead to subtle bugs if permission definitions change or if IDs are reordered or extended in the future. Suggestion: Clarify the model by either: - renaming permission_id to access_level consistently, or - introducing a proper permission mapping layer instead of casting raw integers. ### How to Reproduce This is a code-level design inconsistency and does not require a UI reproduction. The issue can be observed by: 1. Inspecting workspace_shared_view_sql.rs where permission_id is stored as a raw i32 in the database. 2. Inspecting manager.rs where the same field is later interpreted and converted into an access level enum. The mismatch becomes apparent by following the data flow between persistence and runtime interpretation. ### Expected Behavior The permission model should be unambiguous. Either: - permission_id should represent a stable permission identifier with a clear mapping layer to access levels, or - the field should be consistently named and treated as access_level across storage and runtime logic. This would improve clarity and reduce the risk of future permission-related bugs. ### Operating System Not OS-specific (code-level issue) ### AppFlowy Version(s) Current main branch ### Screenshots _No response_ ### Additional Context _No response_