# `Profile` System Permission Repair Checklist

This document records the first repair/validation pass for the `Profile` permission issue so future follow-up work can quickly reuse the same context and evidence.

## Background

- Related issue: [#1808](https://github.com/pingcap-inc/MetaDrivenPlatform4AI/issues/1808)
- Repair PR: [#1846](https://github.com/pingcap-inc/MetaDrivenPlatform4AI/pull/1846)
- Validation date: `2026-04-24`

One-sentence problem statement:

> Migrated `PermissionSet` rows already carried `Permissions*` boolean facts, but `_System_PermissionSetPermission` was not synchronized/backfilled, so effective permissions dropped some system grants and Setup entries were hidden incorrectly.

## What this repair covers

This repair only covers the system-permission chain below:

`Profile -> profile-owned PermissionSet -> _System_PermissionSetPermission -> effective permissions`

In practical terms, the goal is to:

- take system permissions that already exist as `PermissionSet.Permissions*` boolean facts
- backfill them into `_System_PermissionSetPermission` during `setup repair`
- let effective permissions read those grants again
- restore Setup entries that depend on those system permissions

## What PR #1846 changed

PR `#1846` adds a backfill step to the `setup repair` flow:

- read existing system-permission boolean columns from `PermissionSet`
- write missing normalized grant rows into `_System_PermissionSetPermission`
- keep the change minimal by only restoring facts that are already `true`

Why this repair is low-risk:

- it does **not** invent new business permissions
- it only re-materializes grants that are already declared on the `PermissionSet`
- it makes `repair` an idempotent recovery path for historical migration gaps

## Repair checklist

### 1. Confirm the issue matches this chain

- [x] The target `PermissionSet` already has the relevant `Permissions*` boolean columns set to `true`
- [x] The corresponding `_System_PermissionSetPermission` rows are missing
- [x] `/permissions/effective` returns the affected system permissions as missing / `null`
- [x] The Setup page hides permission-gated entries

### 2. Run the repair

- [x] Execute `go run ./cmd/setup repair` with code that contains `#1846`
- [x] Confirm the log contains `BackfillPermissionSetPermissionSSoT`
- [x] Confirm the reported inserted row count matches the expected missing grants

### 3. Validate the result

- [x] SQL shows the missing `_System_PermissionSetPermission` rows were restored
- [x] Re-login shows the same system permissions as `true` in `/permissions/effective`
- [x] The previously hidden Setup entries become visible again

## Validation sample

- `Profile`: `AI Agent Profile`
- `ProfileId`: `00eRC00000B0nlZYAR`
- `PermissionSetId`: `0PSRC000000BX2H4AW`
- Test user: `ci-profile-validate-1776998334155@example.com`

System permissions validated in this round:

- `ManageSharing`
- `ManageRoles`

## Evidence

### 1. Current user permission configuration

This screenshot captures the exact validation user plus the broken permission state before repair:

- the profile-owned `PermissionSet` already has `PermissionsManageSharing = true`
- the profile-owned `PermissionSet` already has `PermissionsManageRoles = true`
- the normalized SSoT rows are still missing

![Current user permission configuration](./assets/profile-current-user-config.png)

### 2. Broken Setup screen

Before repair, the Setup page does **not** show:

- `Public Groups`
- `Roles`
- `Sharing Rules`

![Setup before repair](./assets/profile-setup-before.png)

### 3. Repaired Setup screen

After `setup repair` and re-login, the Setup page shows:

- `Public Groups`
- `Roles`
- `Sharing Rules`

![Setup after repair](./assets/profile-setup-after.png)

## Conclusion from this round

This validation proves:

- the issue is not a frontend rendering bug
- the root cause is the missing sync/backfill from `PermissionSet` boolean facts to `_System_PermissionSetPermission`
- once `setup repair` restores those normalized grant rows, effective permissions and Setup visibility recover together

The direct end-user impact is:

- pages that users should already have access to become visible again
- the clearest examples in this round are `Public Groups`, `Roles`, and `Sharing Rules`

## What is still out of scope

This round does **not** validate:

- `ObjectPermissions`
- `FieldPermissions`

So issues such as “why does add/edit user only show a very small set of fields” still require a second validation track and should not be considered fixed by `#1846`.