feat: 路由增加perms配置项 #4706
feat: 路由增加perms配置项 #4706
Conversation
menglidong
requested review from
anncwb,
vince292007 and
a team
as code owners
|
WalkthroughThe changes in this pull request involve modifications to the Changes
Possibly related PRs
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (7)
packages/effects/access/src/accessible.ts (2)
45-45: LGTM! Consider adding a type annotation for clarity.The addition of
accessCodesto thegenerateRoutesfunction aligns well with the PR objectives. The implementation looks correct and maintains backward compatibility.For improved clarity, consider adding a type annotation for
accessCodes:- const { forbiddenComponent, roles, routes, accessCodes } = options; + const { forbiddenComponent, roles, routes, accessCodes }: { accessCodes?: string[] } = options;This change would make the expected type of
accessCodesmore explicit.Also applies to: 57-57
Missing
accessCodesinGenerateMenuAndRoutesOptionstypeThe
accessCodesproperty is not included in theGenerateMenuAndRoutesOptionstype. This omission can lead to TypeScript errors and potential runtime issues.
- File:
@vben/types- AddaccessCodestoGenerateMenuAndRoutesOptions.🔗 Analysis chain
Line range hint
1-87: Verify completeness ofaccessCodesimplementationThe changes to add
accessCodesare well-implemented in thegenerateRoutesfunction. However, to ensure full support for this new functionality:
- Check if the
GenerateMenuAndRoutesOptionstype (imported from@vben/types) has been updated to include theaccessCodesproperty.- Verify if the
generateAccessiblefunction needs to handleaccessCodesin any way.Run the following script to check these:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of accessCodes across related files # Test 1: Check if GenerateMenuAndRoutesOptions includes accessCodes echo "Checking GenerateMenuAndRoutesOptions definition:" rg -A 5 "type GenerateMenuAndRoutesOptions" # Test 2: Check if generateAccessible function handles accessCodes echo "Checking generateAccessible function:" rg -A 10 "function generateAccessible" # Test 3: Check for any other occurrences of accessCodes echo "Checking for other occurrences of accessCodes:" rg "accessCodes"Length of output: 3292
apps/web-naive/src/router/guard.ts (1)
104-104: LGTM! Consider adding a comment for clarity.The addition of
accessCodesto thegenerateAccessfunction call enhances the access control logic by incorporating user-specific access codes. This change aligns well with the PR objectives and is consistent with similar modifications in other parts of the codebase.Consider adding a brief comment explaining the purpose of
accessCodesfor better code readability:const { accessibleMenus, accessibleRoutes } = await generateAccess({ + // Include user-specific access codes for granular permission control accessCodes: accessStore.accessCodes || [], roles: userRoles, router, // 则会在菜单中显示，但是访问会被重定向到403 routes: dynamicRoutes, });apps/web-antd/src/router/guard.ts (1)
105-105: LGTM! Consider adding a comment for clarity.The addition of
accessCodesto thegenerateAccessfunction call is a good implementation of the newpermsconfiguration for routing. It enhances access control by incorporating user-specific access codes while maintaining backward compatibility.Consider adding a brief comment explaining the purpose of
accessCodesfor better code readability:const { accessibleMenus, accessibleRoutes } = await generateAccess({ + // User-specific access codes for granular permission control accessCodes: accessStore.accessCodes || [], roles: userRoles, router, // 则会在菜单中显示，但是访问会被重定向到403 routes: dynamicRoutes, });apps/web-ele/src/router/guard.ts (1)
105-108: LGTM! Consider adding a comment for clarity.The addition of
accessCodesto thegenerateAccessfunction call aligns well with the PR objectives to introduce a newpermsconfiguration for routing. This change allows for more granular control over user permissions based on access codes.Consider adding a brief comment explaining the purpose of the
accessCodesparameter for better code readability:const { accessibleMenus, accessibleRoutes } = await generateAccess({ + // Use access codes for granular permission control accessCodes: accessStore.accessCodes || [], roles: userRoles, router, // 则会在菜单中显示，但是访问会被重定向到403 routes: dynamicRoutes, });packages/utils/src/helpers/generate-routes-frontend.ts (2)
49-53: Update the documentation forhasPermsfunctionThe comments for the
hasPermsfunction are currently identical to those ofhasAuthority. Please update the comments to accurately describe the purpose and parameters ofhasPerms, ensuring clarity for future maintainers.
54-62: Enhance parameter naming for clarity and consistencyIn the
hasPermsfunction, consider renaming the parameteraccesstoaccessCodesto clearly indicate that it represents access codes. This aligns with the parameter naming ingenerateRoutesByFrontendand improves code readability.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (6)
- apps/web-antd/src/router/guard.ts (1 hunks)
- apps/web-ele/src/router/guard.ts (1 hunks)
- apps/web-naive/src/router/guard.ts (1 hunks)
- packages/@core/base/typings/src/vue-router.d.ts (2 hunks)
- packages/effects/access/src/accessible.ts (2 hunks)
- packages/utils/src/helpers/generate-routes-frontend.ts (2 hunks)
🧰 Additional context used
🔇 Additional comments (2)
packages/@core/base/typings/src/vue-router.d.ts (2)
105-108: LGTM: Newpermsproperty aligns with PR objectivesThe addition of the
perms?: string[]property to theRouteMetainterface is consistent with the PR's goal of introducing a new configuration option for routing. This optional property allows for specifying permission codes required for access, enhancing the granularity of access control in the routing system.
128-128: LGTM: NewaccessCodesproperty complements thepermsadditionThe introduction of the
accessCodes?: string[]property in theGenerateMenuAndRoutesOptionsinterface is a logical complement to thepermsproperty. This optional property allows for passing access codes when generating menus and routes, which aligns with the PR's objective of utilizingaccessCodesfor permission data in the routing system.
| if (!route.meta?.authority) { | ||
| return hasPerms(route, accessCodes); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider refactoring to reduce code duplication between hasAuthority and hasPerms
The functions hasAuthority and hasPerms share similar logic for access checks based on route metadata. To improve maintainability and reduce redundancy, consider refactoring these functions to share common code or merging them if appropriate.
| @@ -8,10 +8,14 @@ import { filterTree, mapTree } from '@vben-core/shared/utils'; | |||
| async function generateRoutesByFrontend( | |||
| routes: RouteRecordRaw[], | |||
| roles: string[], | |||
| accessCodes: string[], | |||
There was a problem hiding this comment.
💡 Codebase verification
Missing accessCodes Parameter in generateRoutesByFrontend Invocations
packages/utils/src/helpers/__tests__/generate-routes-frontend.test.ts: Several test cases are missing theaccessCodesparameter.packages/effects/access/src/accessible.ts: Invocation ofgenerateRoutesByFrontenddoes not includeaccessCodes.
🔗 Analysis chain
Ensure all invocations of generateRoutesByFrontend include the new accessCodes parameter
The addition of the accessCodes parameter to the generateRoutesByFrontend function requires updating all places where this function is called. Please verify that all invocations pass the appropriate accessCodes to prevent potential runtime errors.
To assist with this verification, you can run the following script to locate all calls to generateRoutesByFrontend:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find all invocations of `generateRoutesByFrontend` and check for the `accessCodes` parameter.
# Search for the function calls to `generateRoutesByFrontend`
rg -A 2 -B 2 'generateRoutesByFrontend\(' --glob '!packages/utils/src/helpers/generate-routes-frontend.ts'
Length of output: 2104
|
It would be great to have this option; sometimes, just role-based permissions are not enough |
Description
路由增加perms配置项
其和authority区别：
Type of change
Please delete options that are not relevant.
Checklist
pnpm run docs:devcommand.pnpm test.feat:,fix:,perf:,docs:, orchore:.Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Documentation
These changes aim to improve user experience by ensuring that access to routes is more accurately tailored to individual user permissions.