feat: init models management#330
Conversation
Summary of ChangesHello @looplj, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a brand new, full-fledged AI model management system. It provides a dedicated section in the application's frontend where users can define and configure various AI models, detailing their capabilities, costs, and usage limits. The system also allows for flexible association of these models with existing channels, supporting different matching strategies including regular expressions. This feature is backed by a new GraphQL API and database schema, ensuring robust and scalable model configuration. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces a comprehensive feature for managing AI models. The changes include a new 'Models' page in the frontend with a data table, create/edit/delete/association dialogs, and the necessary context and data fetching logic. On the backend, a new Model entity is added to the database schema, along with business logic and GraphQL APIs to support the frontend functionality. The overall implementation is well-structured and follows modern development practices. I've identified a few areas for improvement, mainly concerning type safety in the frontend, removal of some unused code, and a potential issue with permission scopes in the backend privacy policy that should be reviewed for correctness.
| const fetchConnections = async () => { | ||
| try { | ||
| const associations: ModelAssociationInput[] = debouncedAssociations | ||
| .filter((assoc: any) => { |
| scopes.APIKeyScopeQueryRule(scopes.ScopeReadChannels), | ||
| scopes.OwnerRule(), // owner 用户可以访问所有渠道 | ||
| scopes.UserReadScopeRule(scopes.ScopeReadChannels), // 需要 Models 读取权限 | ||
| }, | ||
| Mutation: scopes.MutationPolicy{ | ||
| scopes.OwnerRule(), // owner 用户可以修改所有渠道 | ||
| scopes.UserWriteScopeRule(scopes.ScopeWriteChannels), // 需要 Models 写入权限 | ||
| }, |
There was a problem hiding this comment.
The privacy policy for the Model entity seems to be using permission scopes related to channels (scopes.ScopeReadChannels, scopes.ScopeWriteChannels). The comments in Chinese suggest that model-specific permissions were intended ("需要 Models 读取权限" means "needs Models read permission"). This could lead to incorrect authorization logic where users with channel permissions can manage models, which might not be the desired behavior. Please verify if this is intentional or if model-specific scopes should be created and used.
| function isDeveloperIcon(icon: string) { | ||
| return Object.values(DEVELOPER_ICONS).includes(icon) | ||
| } |
| const [developerSearchValue, setDeveloperSearchValue] = useState<string>('') | ||
| const [modelIdInput, setModelIdInput] = useState<string>('') | ||
| const [modelIdSearchValue, setModelIdSearchValue] = useState<string>('') | ||
| const [_selectedModelCard, setSelectedModelCard] = useState<ModelCard>({}) |
| const iconOptions = useMemo(() => { | ||
| return ( | ||
| Object.entries(toc) | ||
| // @ts-ignore |
There was a problem hiding this comment.
The use of @ts-ignore here and in other places (e.g., models-columns.tsx) to handle types from @lobehub/icons should be avoided. It seems the type of toc is not specific enough. Please consider adding a local type definition for the icon objects or using a type assertion like as { group: string; id: string } to ensure type safety and improve code quality.
| const formatTokens = (num?: number) => { | ||
| if (!num) return '' | ||
| if (num >= 1000) return `${(num / 1000).toFixed(0)}K` | ||
| return num.toString() | ||
| } |
| return ( | ||
| <div className='flex items-center justify-center'> | ||
| {IconComponent ? ( | ||
| //@ts-ignore |
| @@ -0,0 +1,29 @@ | |||
| import { record } from 'zod' | |||
No description provided.