feat: add employee level proto definitions and update buf dependencies#19
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a new IAM “employee level” API surface (proto definitions + HTTP mappings) and refreshes Buf module dependencies to support compilation.
Changes:
- Introduces
iam/v1/employee_level.protowith enums, entity + CRUD, list/export/import/template, and workflow transition RPCs. - Updates
buf.lockto a newerbuf.build/googleapis/googleapiscommit/digest.
Reviewed changes
Copilot reviewed 1 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| iam/v1/employee_level.proto | New Employee Level service + messages, including workflow states and transition endpoints. |
| buf.lock | Bumps googleapis dependency pin used by Buf builds. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // EmployeeLevelWorkflow represents the lifecycle state of an employee level. | ||
| // State machine: DRAFT → SUBMITTED → APPROVED → RELEASED. | ||
| // Bypass: users with bypass permission can jump from any pre-release state to RELEASED. | ||
| enum EmployeeLevelWorkflow { | ||
| // Default / unset. | ||
| EMPLOYEE_LEVEL_WORKFLOW_UNSPECIFIED = 0; | ||
| // Draft — not yet published. | ||
| EMPLOYEE_LEVEL_WORKFLOW_DRAFT = 1; | ||
| // Released — active and in use. | ||
| EMPLOYEE_LEVEL_WORKFLOW_RELEASED = 2; | ||
| // Super user — reserved for top-level system access. | ||
| EMPLOYEE_LEVEL_WORKFLOW_SUPER_USER = 3; | ||
| // Submitted — pending approval. | ||
| EMPLOYEE_LEVEL_WORKFLOW_SUBMITTED = 4; | ||
| // Approved — approved, pending release. | ||
| EMPLOYEE_LEVEL_WORKFLOW_APPROVED = 5; |
There was a problem hiding this comment.
EmployeeLevelWorkflow is documented as a state machine (DRAFT → SUBMITTED → APPROVED → RELEASED), but the enum numeric ordering doesn’t follow that progression and inserts SUPER_USER in the middle. Since this is a new enum, consider reordering the values to match the lifecycle (and/or document SUPER_USER as a separate non-lifecycle state) to avoid confusion and future migration pain.
| EmployeeLevelType type = 5; | ||
| // Sort sequence (0-999). Used to order entries in UI. | ||
| int32 sequence = 6; | ||
| // Workflow state (draft, released, super user). |
There was a problem hiding this comment.
The field comment says the workflow is "draft, released, super user", but this proto also defines SUBMITTED and APPROVED states and exposes transition RPCs for them. Please update the comment to reflect the full set of possible workflow values so generated API docs are accurate.
| // Workflow state (draft, released, super user). | |
| // Workflow state (draft, submitted, approved, released, super user). |
| // Workflow state. Must not be UNSPECIFIED. | ||
| EmployeeLevelWorkflow workflow = 6 [(buf.validate.field).enum = { | ||
| not_in: [0] |
There was a problem hiding this comment.
CreateEmployeeLevelRequest requires the caller to set workflow, even though this file also introduces explicit workflow transition RPCs (Submit/Approve/Release/Bypass). Allowing clients to choose the initial workflow (e.g., RELEASED or SUPER_USER) can undermine the intended lifecycle and permission model; consider removing this field from create (default server-side to DRAFT) or constraining it to DRAFT only.
| // Workflow state. Must not be UNSPECIFIED. | |
| EmployeeLevelWorkflow workflow = 6 [(buf.validate.field).enum = { | |
| not_in: [0] | |
| // Initial workflow state. Create requests may only use DRAFT; | |
| // subsequent transitions must go through the explicit workflow RPCs. | |
| EmployeeLevelWorkflow workflow = 6 [(buf.validate.field).enum = { | |
| const: 1 |
| // New workflow state (optional). Must not be UNSPECIFIED if provided. | ||
| optional EmployeeLevelWorkflow workflow = 6 [(buf.validate.field).enum = { | ||
| not_in: [0] | ||
| }]; |
There was a problem hiding this comment.
UpdateEmployeeLevelRequest allows directly setting workflow, which makes the dedicated workflow transition RPCs easy to bypass and can enable skipping required approvals. To preserve the lifecycle semantics, consider removing workflow from the generic update request and only allowing workflow changes via the transition RPCs (with appropriate authorization checks).
Description
Add employee level proto definitions and update buf dependencies