[18.0][ADD] vault_portal: portal access to shared vaults - #983
Open
cvinh wants to merge 1 commit into
Open
Conversation
cvinh
force-pushed
the
18.0-add_vault_portal
branch
2 times, most recently
from
August 21, 2026 12:58
7f0ba30 to
d29ad30
Compare
cvinh
marked this pull request as ready for review
August 21, 2026 13:01
cvinh
force-pushed
the
18.0-add_vault_portal
branch
from
August 22, 2026 01:29
d29ad30 to
2003667
Compare
Contributor
Author
|
@jans23 it would supercool if you review this 99% AI coded module... we deployed it in test and it looks like ok... |
cvinh
marked this pull request as draft
August 22, 2026 01:32
cvinh
force-pushed
the
18.0-add_vault_portal
branch
6 times, most recently
from
August 24, 2026 06:26
9896025 to
e51639c
Compare
Contributor
|
My colleague would be better positioned for reviewing. @KDRdev could you review it please? |
cvinh
force-pushed
the
18.0-add_vault_portal
branch
4 times, most recently
from
August 24, 2026 07:11
f679355 to
bec3f00
Compare
cvinh
marked this pull request as ready for review
August 24, 2026 07:15
cvinh
marked this pull request as draft
August 25, 2026 02:12
Contributor
Author
|
still WIP |
cvinh
force-pushed
the
18.0-add_vault_portal
branch
3 times, most recently
from
August 25, 2026 16:54
89670e4 to
4326b21
Compare
Extends vault (OCA/server-auth) to let portal contacts view and, where explicitly granted per contact, edit or add password field values from their own portal account. Access stays strictly per individual, end-to-end encrypted exactly like internal users: each contact holds their own key pair, and the vault's master key is re-wrapped for them individually. Two clients never share any key material. Read-only by default at every layer (model access, ir.rule and vault.abstract.check_access(), unchanged from "vault"): the vault itself and entry names always stay read-only from the portal; only the value of a vault.field can be written, gated by vault.right.perm_write/perm_create per contact. An optional MFA policy (Settings > Vault) can require two-factor authentication before a portal contact is granted write access, or any access at all; disabling 2FA afterwards applies the same policy in reverse. Assisted-by: Claude Sonnet 5
cvinh
force-pushed
the
18.0-add_vault_portal
branch
from
August 25, 2026 18:51
4326b21 to
2d9dbc1
Compare
cvinh
marked this pull request as ready for review
August 25, 2026 19:03
Contributor
Author
|
ready for review |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Extends vault (OCA/server-auth) to let portal contacts view and, where explicitly granted per contact, edit or add password field values from their own portal account.
Access stays strictly per individual, end-to-end encrypted exactly like internal users: each contact holds their own key pair, and the vault's master key is re-wrapped for them individually. Two clients never share any key material.
Read-only by default at every layer (model access, ir.rule and vault.abstract.check_access(), unchanged from "vault"): the vault itself and entry names always stay read-only from the portal; only the value of a vault.field can be written, gated by
vault.right.perm_write/perm_create per contact.
An optional MFA policy (Settings > Vault) can require two-factor authentication before a portal contact is granted write access, or any access at all; disabling 2FA afterwards applies the same policy in reverse.
Assisted-by: Claude Sonnet 5