fix: implement permission validation for NewcomerGrowthEndpoints

[fulingwei1]

Resolved 4 TODO items by implementing proper authorization checks:

• GetPersonalGrowthCurve: Users can only view their own data unless they're a manager/admin
• GetTeamAverageGrowthCurve: Only managers/admins can view team data
• GetGrowthMilestones: Users can only view their own milestones unless they're a manager/admin
• CalculateGrowthMetrics: Users can only calculate their own metrics unless they're a manager/admin

Added IsManagerOrAdminAsync helper method following the pattern used in SmartThresholdEndpoints.

---

Note

Major backend expansion and auth fixes.

• Adds employee management endpoints: import/excel|json|template, single/batch activate, export (Excel/CSV with preview), and update (batch, template generation, Excel parsing)
• Introduces async import task API: task status/detail, query, delete, cleanup; plus background processing hooks
• Adds field-problem endpoints incl. generate-from-ticket, detect-repeat, statistics/hotspots, and by-ticket/{id} fetch
• Adds solution recommendation endpoints: recommend, solution stats, version compatibility, ticket similarity
• Extends auth with username/password login, change/reset password endpoints
• Adds operation log querying/statistics/cleanup endpoints
• Updates NewcomerGrowthEndpoints to enforce manager/admin checks and self-access restrictions
• Includes DB migrations: user fields, operation_logs, import_tasks, field_problems table, ticket tags (JSONB + GIN)
• Adds comprehensive documentation and migration/utility scripts

^{Written by Cursor Bugbot for commit d33bcb4. This will update automatically on new commits. Configure here.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Custom headers drop Authorization token

When building request options the code merges ...options after the computed headers, so any call that passes a headers object replaces the merged headers and silently strips the Authorization token. For endpoints that require auth and also need custom headers (e.g., multipart uploads via request.post(..., { headers: { 'Content-Type': 'multipart/form-data' } })), the request now goes out without auth and receives 401s. The merge order should preserve the token when custom headers are supplied.

Useful? React with 👍 / 👎.

[cursor]

Permission check uses non-existent "Manager" role

The IsManagerOrAdminAsync method checks for Role == "Manager", but "Manager" is not a valid role in the system. The valid roles defined in EmployeeUpdateService.cs are: "Admin", "FieldEngineer", "CS", and "SeniorEngineer". This means the permission check will only ever pass for Admin users, making the "manager" portion of the authorization logic non-functional. Users who should have manager-level access (likely SeniorEngineer based on their described permissions) will be denied access to other users' growth data.

 

[cursor]

Password validation doesn't enforce documented security requirements

The ChangePasswordAsync and ResetPasswordAsync methods only validate that passwords are at least 6 characters long. However, the documentation in LOGIN_GUIDE.md and EMPLOYEE_IMPORT_GUIDE.md explicitly states passwords must be at least 8 characters and contain uppercase letters, lowercase letters, and digits. This backend validation gap allows weak passwords like "aaaaaa" to be set by anyone who bypasses the frontend, creating a significant security risk since password complexity requirements are not enforced server-side.

Additional Locations (1)

• backend/src/FieldTicket.Infrastructure/Services/AuthService.cs#L404-L408

 

[cursor]

Admin-created users cannot log in immediately

When an admin creates a user through the POST /api/users endpoint, the IsActivated field is not set and defaults to false (per User.cs line 46). Since PasswordLoginAsync checks IsActivated and rejects users where it's false, admin-created password-login users will be unable to log in until separately activated. Unlike the batch import workflow where activation is an intentional review step, single-user creation by an admin likely expects the user to be immediately usable. The endpoint should either set IsActivated = true or accept it as a request parameter.

 

[cursor]

Re-import deactivates existing user accounts unexpectedly

When re-importing employees with overwriteExisting=true, the code unconditionally sets user.IsActivated = false for existing users. This will deactivate accounts that were previously activated, locking out users who are actively using the system. They will receive "账户未开通，请联系管理员" error and cannot log in until an admin manually re-activates their account. The activation status of existing users should be preserved during updates, or only set to false for newly created users.

 

[cursor]

Duplicate names cause incorrect supervisor assignments in import

The userMap dictionary uses employee name as the key. If multiple employees with the same name are imported in a single batch, later entries overwrite earlier ones in the map. During the second pass that sets supervisor relationships, all employees with the same name will reference the last User entity added, causing the first employee's supervisor relationship to be set on the wrong user object. The map key should use a unique identifier rather than the name.

Additional Locations (1)

• backend/src/FieldTicket.Api/Endpoints/EmployeeImportEndpoints.cs#L309-L312

 

[cursor]

Authorization uses non-existent "Engineer" role

The [Authorize(Roles = "Admin,Engineer")] attribute on the GenerateFromTicket endpoint references an "Engineer" role that doesn't exist in the system. The valid roles are Admin, SeniorEngineer, FieldEngineer, and CS. Since no user will ever have the "Engineer" role, only Admin users can access this endpoint. The intention was likely to allow SeniorEngineer or FieldEngineer users to generate field problems from tickets.

 

[cursor]

Duplicate names in import batch cause database failure

The ProcessImport method checks for existing users by querying the database (dbContext.Users.FirstOrDefaultAsync), but doesn't check for duplicates already added to the DbContext in the current batch. If an Excel file contains two rows with the same name, both will pass validation (since neither is in the database yet), both will be added to the DbContext, and SaveChangesAsync() will fail with a unique constraint violation on Username. The userMap dictionary exists but isn't used to detect within-batch duplicates before creating new users.

 

[cursor]

Password-login users can be created without passwords

The CreateUser endpoint only sets PasswordHash when LoginType == "Password" AND Password is not empty. If an admin creates a user with LoginType = "Password" but leaves the password field empty or null, the user is saved without a PasswordHash. Such users can never log in because PasswordLoginAsync checks string.IsNullOrEmpty(user.PasswordHash) and rejects the attempt. The API lacks validation to require a password when LoginType is set to "Password".

 

[cursor]

Invalid PostgreSQL syntax for partial unique constraint

The SQL statement ALTER TABLE ... ADD CONSTRAINT ... UNIQUE ... WHERE is invalid PostgreSQL syntax. PostgreSQL does not support the WHERE clause on ADD CONSTRAINT UNIQUE. This migration script will fail with a syntax error when executed. To create a partial unique constraint, use CREATE UNIQUE INDEX "UQ_Users_Username" ON "Users" ("Username") WHERE "Username" IS NOT NULL instead.

 

[cursor]

Delete task endpoint returns success without deleting

The DeleteTask endpoint has a TODO comment indicating the delete logic needs to be implemented, and the actual deletion call asyncTaskService.DeleteTaskAsync(taskId) is commented out. However, the endpoint still returns Results.Ok(new { message = "任务已删除" }) (task deleted). This causes the API to mislead callers into believing the task was successfully deleted when nothing was actually deleted, leading to data inconsistency and user confusion.

 

[cursor]

Role claim type mismatch breaks ticket access control

The GetUserRole function uses ClaimTypes.Role (which resolves to "http://schemas.microsoft.com/ws/2008/06/identity/claims/role") to look up the user's role, but JwtTokenService.GenerateToken creates claims with the simple string "role". This mismatch causes GetUserRole to always return null, making role-based filtering ineffective. As a result, FieldEngineers can view and search all tickets instead of only their own, bypassing the intended permission restrictions. The fix is to use c.Type == "role" like other endpoints in this PR (e.g., EmployeeImportEndpoints).

Additional Locations (1)

• backend/src/FieldTicket.Api/Endpoints/TicketEndpoints.cs#L478-L484

 

[cursor]

Permission bypass when user ID claim is malformed

The QueryTasks method's permission check has flawed logic. The condition currentUserRole != "Admin" && Guid.TryParse(currentUserId, out var userId) means that if a non-admin user has a JWT with a missing or malformed "sub" claim, the Guid.TryParse fails, the entire condition becomes false, and request.CreatedById is never set. This allows the user to see all import tasks instead of just their own. The DeleteTask method handles this edge case correctly by returning Forbid() when the user ID cannot be parsed, but QueryTasks does not.