Education #151
Open
Education #151
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Added backend support for course categories: - Updated TypeScript types and DB definitions - Added custom GraphQL resolver for course categories - Implemented frontend UI for course category management: - New components for adding and listing course categories - Added form validation schema and hooks for category creation - Integrated category UI into CoursesHeader and Course pages - Updated Add Class and Add Course flows to support categories - Modified GraphQL queries and mutations accordingly - Updated project config and lock file for consistency
- Deleted old CourseDetail.tsx component - Created new modular structure under 'components', 'graphql', 'hooks', and 'states' - Added: - CourseDetail.tsx - CourseDetailGeneral.tsx - CourseDetailLayout.tsx - CourseDetailSheet.tsx - GraphQL query: courseDetail.tsx - Hook: useCourseDetail.tsx - State management: courseDetailStates.tsx - Updated AddCoursePage and CourseIndexPage to integrate new structure
- Updated backend: schema, models, types, and resolvers - Refactored frontend: course form split into steps - Added new fields: ClassIdField, SelectDaysField - Updated GraphQL queries and mutations for course operations
… typeDefs; implement comments module; enhance course detail UI - Deleted deprecated apolloServer.ts and split schema into typeDefs and resolvers. - Added full comments module with DB definitions, GraphQL resolvers, and schemas. - Refactored courses schema and types to support new features. - Improved frontend UI: added CourseAttendances and CourseDetailActions components, and updated existing course detail components for better structure and interactivity.
- Implemented teachers backend with types, models, resolvers, and schema - Added frontend module for teachers management including: - AddTeacherForm, TeacherTable, TeacherHeader, and supporting components - GraphQL queries and mutations - Hooks and types for data handling - Updated existing resolver and schema files for integration - Removed deprecated course utilities and extensions
- Added ClassCommandBar and CourseCommandBar components - Renamed course-related components for consistency (Courses* -> Course*) - Updated course and class record tables with relevant changes - Modified CourseIndexPage and config for updated component structure
Reviewer's GuideThis PR introduces a full “Education” plugin with frontend and backend support for courses, classes, categories, teachers, and comments. On the frontend, it adds multi-step forms, record tables, detail sheets, side panels with action tabs, and data hooks all built on erxes-ui, React Hook Form/Zod, Apollo client and Jotai for state. On the backend, it defines GraphQL schemas/queries/mutations, custom resolvers, Mongoose models with business logic (order generation, searchText), cursor pagination, and TRPC context generation. Sequence Diagram for Adding a New CoursesequenceDiagram
actor User
participant AddCourseForm as AddCourseForm (UI)
participant useAddCourse as useAddCourse Hook
participant GraphQLAPI as GraphQL API (education_api)
participant CourseMutations as Course Mutations Resolver
participant CourseModel as Course Model (Mongoose)
participant Database
User->>AddCourseForm: Fills Core Info (Step 1)
User->>AddCourseForm: Clicks Next
User->>AddCourseForm: Fills Schedule Info (Step 2)
User->>AddCourseForm: Clicks Next
User->>AddCourseForm: Fills Utils Info (Step 3)
User->>AddCourseForm: Clicks Submit
AddCourseForm->>useAddCourse: courseAdd(formData)
useAddCourse->>GraphQLAPI: mutation courseAdd(...)
GraphQLAPI->>CourseMutations: courseAdd(doc, models)
CourseMutations->>CourseModel: createCourse(doc)
CourseModel->>Database: Store course data
Database-->>CourseModel: Course created successfully
CourseModel-->>CourseMutations: Returns new course document
CourseMutations-->>GraphQLAPI: Returns new course data
GraphQLAPI-->>useAddCourse: Success response (new course)
useAddCourse->>AddCourseForm: onCompleted() callback
AddCourseForm->>User: Display success toast
AddCourseForm->>User: Navigate to previous page
Entity Relationship Diagram for Education Plugin ModelserDiagram
User {
String _id PK "User ID (External)"
String email
Json details
}
CourseCategory {
String _id PK
String name
String code
String order
String parentId FK "Parent Category ID"
String description
}
Classes {
String _id PK
String name
String description
String location
String level
}
Course {
String _id PK
String name
String categoryId FK
String classId FK
String description
String type
String status
Date startDate
Date endDate
Float unitPrice
Int limit
String location
String primaryTeacherId FK "User ID"
}
Comment {
String _id PK
String courseId FK
String parentId FK "Parent Comment ID"
String content
}
Teacher {
String _id PK
String userId FK "User ID"
}
CourseCategory }o--o| CourseCategory : "has parent"
CourseCategory ||--|{ Course : "categorizes"
Classes ||--|{ Course : "hosts"
Course ||--o{ Teacher : "has teachers"
Teacher ||--|| User : "is a"
Course ||--|| User : "has primary teacher (User)"
Course ||--|{ Comment : "has comments"
Comment }o--o| Comment : "is reply to"
Class Diagram for Course Model (Backend)classDiagram
class Course {
+String _id
+String name
+String categoryId
+String classId
+String description
+Date createdAt
+String type
+Attachment attachment
+String status
+Date startDate
+Date endDate
+Date deadline
+Float unitPrice
+Int commentCount
+User primaryTeacher
+User[] teachers
+Int limit
+String location
+String searchText
+Date modifiedAt
+static fillSearchText(doc: ICourse): String
+static getCourse(_id: String): Promise<ICourseDocument>
+static createCourse(doc: ICourse): Promise<ICourseDocument>
+static updateCourse(_id: String, doc: ICourse): Promise<ICourseDocument>
+static removeCourses(courseIds: String[]): Promise<void>
}
class Attachment {
url: String
name: String
type: String
size: Number
duration: Number
}
class User {
_id: String
}
Course --> "*" User : teachers
Course --> "1" User : primaryTeacher
Course --> "1" Attachment : attachment
Class Diagram for CourseCategory Model (Backend)classDiagram
class CourseCategory {
+String _id
+String name
+String description
+String parentId
+String code
+String order
+Boolean isRoot
+Int courseCount
+Attachment attachment
+static getCourseCategory(selector: any): Promise<ICourseCategoryDocument>
+static createCourseCategory(doc: ICourseCategory): Promise<ICourseCategoryDocument>
+static updateCourseCategory(_id: String, doc: ICourseCategory): Promise<ICourseCategoryDocument>
+static removeCourseCategory(_id: String): Promise<void>
+static generateOrder(parentCategory: any, doc: ICourseCategory): Promise<String>
}
class Attachment {
url: String
name: String
type: String
size: Number
duration: Number
}
CourseCategory --> "1" Attachment : attachment
Class Diagram for Classes Model (Backend)classDiagram
class Classes {
+String _id
+String name
+String description
+String location
+String level
+Date createdAt
+Date updatedAt
+static getClass(_id: String): Promise<IClassDocument>
+static createClass(doc: IClass): Promise<IClassDocument>
+static updateClass(_id: String, doc: IClass): Promise<IClassDocument>
+static removeClasses(classIds: String[]): Promise<void>
}
Class Diagram for Comment Model (Backend)classDiagram
class Comment {
+String _id
+String courseId
+String parentId
+String content
+Int childCount
+Date createdAt
+Date updatedAt
+static getComment(_id: String): Promise<ICommentDocument>
+static createComment(doc: IComment): Promise<ICommentDocument>
+static deleteComment(_id: String): Promise<void>
}
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Important Review skippedMore than 25% of the files skipped due to max files limit. The review is being skipped to prevent a low-quality review. 95 files out of 202 files are above the max files limit of 100. Please upgrade to Pro plan to get higher limits. You can disable this status message by setting the ✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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 (
|
![ellipsis-dev[bot]](https://avatars.githubusercontent.com/in/64358?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Changes requested ❌
Reviewed everything up to a0126d2 in 3 minutes and 27 seconds. Click for details.
- Reviewed
7130lines of code in177files - Skipped
6files when reviewing. - Skipped posting
11draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. frontend/plugins/education_ui/src/modules/courses/hooks/useClasses.tsx:52
- Draft comment:
The updateQuery function writes the updated data to a property named 'classCourse' instead of 'courseClasses', which may lead to cache inconsistencies. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
2. frontend/plugins/education_ui/src/modules/courses/edit-course/PriceField.tsx:39
- Draft comment:
Consider removing the commented-out alternative for CurrencyDisplay to keep the code clean. - Reason this comment was not posted:
Confidence changes required:50%<= threshold50%None
3. frontend/plugins/education_ui/src/modules/courses/graphql/fragments/userQueryFragment.ts:12
- Draft comment:
Ensure that the fragment 'WorkspaceMemberQueryFragment' is defined and imported, otherwise it may cause runtime errors. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is asking the author to ensure that a fragment is defined and imported, which is similar to asking them to double-check or verify something. This violates the rule against asking the author to confirm or ensure things. The comment does not provide a specific suggestion or point out a clear issue, so it should be removed.
4. backend/plugins/education_api/package.json:11
- Draft comment:
The package.json file has empty 'description', 'author', and 'keywords' fields. Consider populating them for improved project metadata. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While technically correct that these fields are empty, this seems like a minor metadata issue that doesn't affect functionality. The fields are optional in package.json. Many internal/private packages leave these fields empty. This feels more like a nice-to-have than a required change. The metadata could be important for documentation and maintainability purposes. Empty fields could make it harder for future developers to understand the package's purpose. Given this appears to be an internal plugin package (education_api) rather than a public npm package, the metadata fields are less critical. The package's purpose is clear from its name and location in the codebase. Delete this comment as it suggests a minor metadata change that isn't critical for functionality and doesn't meet the bar of being a clearly required code change.
5. backend/plugins/education_api/src/modules/comments/db/models/Comments.ts:16
- Draft comment:
Typo: 'Retreives comment' should be corrected to 'Retrieves comment'. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While this is technically correct, typo fixes in comments are very minor issues. The rules state we should not make comments that are obvious or unimportant. Documentation typos, while worth fixing, don't impact functionality and are quite trivial. The suggestion is clear and actionable, but may not meet the bar for importance. The typo could potentially confuse future developers reading the documentation. Documentation quality is important for maintainability. While documentation is important, this particular typo is extremely minor and obvious - any reader would understand the intent despite the typo. Delete the comment. While correct, it's too minor of an issue to warrant a PR comment.
6. backend/plugins/education_api/src/modules/courses/db/definitions/course.ts:36
- Draft comment:
Typo: 'Finsh' should be 'Finish' in the label of the 'deadline' field. Please correct the spelling before merging. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% The typo is in a label field which likely appears in the UI. While UI text corrections are generally good, our rules specifically state not to comment on pure frontend/UI changes. Labels are primarily used for display purposes. Additionally, this is a new file, so the author may still be working on the text content. The typo could affect user experience and searchability of the interface. It's a clear, objective error that's easy to fix. However, per our rules, we should not comment on UI/frontend changes - we should trust that the author will handle UI text appropriately. Following our rules strictly, we should delete this comment since it relates to UI text content rather than logic.
7. backend/plugins/education_api/src/modules/courses/db/models/Categories.ts:27
- Draft comment:
Typo: 'Cagegory' should be 'Category' in the comment. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is technically correct, it's a very minor documentation typo that doesn't affect functionality. The rules state not to make comments that are obvious or unimportant. Additionally, there's another inconsistency - the method is named getActivityCategory while the comment refers to Course Category, suggesting there might be larger naming issues at play. The typo could be indicative of broader documentation issues that should be addressed. Poor documentation can lead to maintenance problems. While documentation quality is important, this specific typo is too minor to warrant a PR comment. It doesn't impact code functionality and fixing it provides minimal value. Delete this comment as it points out an unimportant typo that doesn't materially impact the code quality or functionality.
8. backend/plugins/education_api/src/modules/courses/db/models/Categories.ts:40
- Draft comment:
Typo: 'course categorys' should be 'course category' or 'course categories'. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is technically correct, it's a very minor documentation issue. The meaning is still clear despite the typo. According to the rules, we should not make purely informative comments or comments about obvious/unimportant issues. Documentation typos that don't affect functionality generally fall into this category. The typo could be seen as affecting code quality and professionalism. Poor documentation can lead to maintenance issues over time. While documentation quality matters, this particular typo is so minor that it doesn't meaningfully impact code understanding or maintenance. The rules specifically say not to make obvious or unimportant comments. This comment should be deleted as it addresses a very minor documentation issue that doesn't impact functionality or code understanding.
9. backend/plugins/education_api/src/modules/courses/db/models/Categories.ts:69
- Draft comment:
Typo: 'Generatingg order' contains an extra 'g' and extra space. It should be corrected to 'Generating order'. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the typo, it's an extremely minor issue in a comment, not in actual code. Comments are for developer documentation and this typo doesn't impact code functionality or significantly impair readability. According to the rules, we should not make comments that are obvious or unimportant. The typo could be seen as reducing code quality and professionalism. Multiple small issues can add up to make code look sloppy. While code quality is important, this is an extremely minor issue in a comment that doesn't affect functionality or significantly impact readability. The effort of creating, reviewing, and addressing this comment outweighs its benefit. Delete this comment as it points out an unimportant typo in a comment that doesn't meaningfully impact code quality.
10. backend/plugins/education_api/src/modules/courses/db/models/Course.ts:20
- Draft comment:
Typo: 'Retreives course' should be 'Retrieves course'. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is technically correct, it's an extremely minor documentation issue. The typo doesn't affect functionality, readability, or searchability of the code. According to the rules, we should not make comments that are obvious or unimportant. Documentation typos generally fall into this category unless they make the documentation misleading. The typo could theoretically make the code slightly less professional looking, and fixing it would improve code quality marginally. The improvement is too minor to warrant a PR comment. This kind of feedback would be better handled through team style guides or automated spell checkers. Delete this comment as it points out an unimportant documentation typo that doesn't meaningfully impact code quality or understanding.
11. frontend/plugins/education_ui/src/modules/courses/graphql/fragments/userQueryFragment.ts:28
- Draft comment:
Typo: 'hasValidEntrepriseKey' may be misspelled. Consider using 'hasValidEnterpriseKey' instead. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a GraphQL schema field name, which means it must match exactly what's defined on the backend. Even if it looks like a typo, changing it would break the API contract. The frontend must use the exact field names from the schema, regardless of spelling. Making this change could cause runtime errors. The spelling does look wrong, and maintaining good spelling in code is generally important for readability. However, GraphQL field names are part of an API contract and must match exactly. Changing field names requires coordination with the backend and would be out of scope for frontend code. Delete this comment. Even if it's a typo, the frontend must use the exact field names defined in the GraphQL schema.
Workflow ID: wflow_4ZHGM36wbmusY9Ja
You can customize 
| */ | ||
| public static async updateCourse(_id, doc) { | ||
| const searchText = this.fillSearchText( | ||
| Object.assign(await models.Courses.createCourse(_id), doc), |
There was a problem hiding this comment.
In the updateCourse method, the code is using models.Courses.createCourse(_id) to retrieve the course document. Likely you intended to use getCourse(_id) to fetch the existing course, avoiding unintended creation.
Suggested change
| Object.assign(await models.Courses.createCourse(_id), doc), | |
| Object.assign(await models.Courses.getCourse(_id), doc), |
| return { list, totalCount, pageInfo }; | ||
| }, | ||
| courseCommentCount: async (_root, { _id }, { models }: IContext) => { | ||
| return models.Comments.find(_id).countDocuments(); |
There was a problem hiding this comment.
The resolver for courseCommentCount uses models.Comments.find(_id).countDocuments(), which is likely incorrect. Consider filtering by a proper field (e.g., { courseId: _id }).
Suggested change
| return models.Comments.find(_id).countDocuments(); | |
| return models.Comments.find({ courseId: _id }).countDocuments(); |
| type: String, | ||
| enum: CLASS_LEVEL_TYPES.ALL, | ||
| default: CLASS_LEVEL_TYPES.Beginner, | ||
| label: 'level', |
There was a problem hiding this comment.
The label for the field level is written in lowercase, whereas the other labels (such as Name, Description, and Location) use title case. Consider capitalizing level to Level for consistency.
Suggested change
| label: 'level', | |
| label: 'Level', |
| parentId: String, | ||
| page: Int, | ||
| perPage: Int, | ||
| cursor: String |
There was a problem hiding this comment.
There appears to be a missing comma between the fields in the queryParams string. After 'cursor: String' (line 24), a comma is expected before 'direction: CURSOR_DIRECTION'. Please verify if a comma is required here.
Suggested change
| cursor: String | |
| cursor: String, |
| searchValue: String | ||
| sortField: String | ||
| sortDirection: Int | ||
| categoryId: String |
There was a problem hiding this comment.
There appears to be a duplicate query parameter categoryId in the queryParams string (lines 62 and 67). If this duplication is not intentional, please remove the redundant instance.
Suggested change
| categoryId: String |
| const queryParams = ` | ||
| page: Int, | ||
| perPage: Int, | ||
| cursor: String |
There was a problem hiding this comment.
Typo: Missing comma after cursor: String in the query parameters string. It should likely be cursor: String, direction: CURSOR_DIRECTION to maintain consistent formatting.
Suggested change
| cursor: String | |
| cursor: String, |
| updateQuery: (prev, { fetchMoreResult }) => { | ||
| if (!fetchMoreResult) return prev; | ||
| return Object.assign({}, prev, { | ||
| classCourse: mergeCursorData({ |
There was a problem hiding this comment.
Typo: The property is named classCourse here, which is inconsistent with the query result (named courseClasses). Please verify if this is a mistake and update it to courseClasses if intended.
Suggested change
| classCourse: mergeCursorData({ | |
| courseClasses: mergeCursorData({ |
| cell: Cell<any, unknown>; | ||
| }) => { | ||
| const [, setOpen] = useQueryState('courseId'); | ||
| const setRenderingContactDetail = useSetAtom(renderingCourseDetailAtom); |
There was a problem hiding this comment.
Typographical inconsistency: The variable name setRenderingContactDetail does not match the atom name renderingCourseDetailAtom. Consider renaming it to setRenderingCourseDetail for clarity and consistency.
|
|
||
| return ( | ||
| <RecordTable.Provider | ||
| columns={productCategoryColumns(categoryObject || {})} |
There was a problem hiding this comment.
Typographical note: There is an inconsistent naming between CourseCategoryRecordTable and the function/ID names (e.g., productCategoryColumns and id 'product-categories'). Consider renaming them for consistency (e.g., to courseCategoryColumns and 'course-categories') to avoid confusion.
| attendances: { | ||
| title: 'Attendances', | ||
| icon: IconCalendarClock, | ||
| code: 'attendaces', |
There was a problem hiding this comment.
Typographical error: In the attendances action tab, the code property is set to 'attendaces'. It should likely be 'attendances' for consistency.
Suggested change
| code: 'attendaces', | |
| code: 'attendances', |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey @Munkhorgilb - I've reviewed your changes - here's some feedback:
- There’s a leftover console.log in AddCourseForm—please remove debug logging before merge.
- In actionTabs config the key 'attendaces' is misspelled—update it to 'attendances' to avoid mismatches.
- The helper
productCategoryColumnsis actually for course categories—consider renaming it tocourseCategoryColumnsfor clarity.
Here's what I looked at during the review
- 🟡 General issues: 9 issues found
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| return ( | ||
| <RecordTable.Provider | ||
| columns={productCategoryColumns(categoryObject || {})} | ||
| data={courseCategories || []} |
There was a problem hiding this comment.
issue (bug_risk): Pass augmented categories including hasChildren
Use the computed categories array as the data prop to ensure hasChildren is included.
| * Get Course Cagegory | ||
| */ | ||
|
|
||
| public static async getActivityCategory(selector: any) { |
There was a problem hiding this comment.
issue (bug_risk): Method name mismatches declared getCourseCategory
Rename the implementation to match the interface method name to prevent type mismatches and potential runtime errors.
| */ | ||
| public static async updateCourse(_id, doc) { | ||
| const searchText = this.fillSearchText( | ||
| Object.assign(await models.Courses.createCourse(_id), doc), |
There was a problem hiding this comment.
issue (bug_risk): Incorrectly using createCourse to fetch existing document
Use getCourse or findOne to retrieve the existing course instead of createCourse, which creates a new record.
| {courseCategories?.map((category: Category) => ( | ||
| <Command.Item | ||
| key={category._id} | ||
| value={category.name} |
There was a problem hiding this comment.
issue: Use category._id for Command.Item value
Set the value prop to category._id to ensure consistency with the onChange logic.
| type Course { | ||
| _id: String! | ||
| name: String | ||
| categoryId: String |
There was a problem hiding this comment.
nitpick: Remove duplicate categoryId in query parameters
There are two 'categoryId' fields in queryParams; please remove one to prevent ambiguity.
Comment on lines
90
to
92
| const removed = await models.CourseCategories.removeCourseCategory(_id); | ||
|
|
||
| return removed; |
There was a problem hiding this comment.
suggestion (code-quality): Inline variable that is immediately returned (inline-immediately-returned-variable)
Suggested change
| const removed = await models.CourseCategories.removeCourseCategory(_id); | |
| return removed; | |
| return await models.CourseCategories.removeCourseCategory(_id); | |
Explanation
Something that we often see in people's code is assigning to a result variableand then immediately returning it.
Returning the result directly shortens the code and removes an unnecessary
variable, reducing the mental load of reading the function.
Where intermediate variables can be useful is if they then get used as a
parameter or a condition, and the name can act like a comment on what the
variable represents. In the case where you're returning it from a function, the
function name is there to tell you what the result is, so the variable name
is unnecessary.
| }; | ||
|
|
||
| export const sortBuilder = (params) => { | ||
| const sortField = params.sortField; |
There was a problem hiding this comment.
suggestion (code-quality): Prefer object destructuring when accessing and using properties. (use-object-destructuring)
Suggested change
| const sortField = params.sortField; | |
| const {sortField} = params; |
Explanation
Object destructuring can often remove an unnecessary temporary reference, as well as making your code more succinct.From the Airbnb Javascript Style Guide
Comment on lines
+50
to
+56
| const { list, totalCount, pageInfo } = await cursorPaginate({ | ||
| model: models.Courses, | ||
| params, | ||
| query: filter, | ||
| }); | ||
|
|
||
| return { list, totalCount, pageInfo }; |
There was a problem hiding this comment.
suggestion (code-quality): Inline variable that is immediately returned (inline-immediately-returned-variable)
Suggested change
| const { list, totalCount, pageInfo } = await cursorPaginate({ | |
| model: models.Courses, | |
| params, | |
| query: filter, | |
| }); | |
| return { list, totalCount, pageInfo }; | |
| return await cursorPaginate({ | |
| model: models.Courses, | |
| params, | |
| query: filter, | |
| }); | |
Explanation
Something that we often see in people's code is assigning to a result variableand then immediately returning it.
Returning the result directly shortens the code and removes an unnecessary
variable, reducing the mental load of reading the function.
Where intermediate variables can be useful is if they then get used as a
parameter or a condition, and the name can act like a comment on what the
variable represents. In the case where you're returning it from a function, the
function name is there to tell you what the result is, so the variable name
is unnecessary.
Comment on lines
6
to
8
| const teacher = await models.Teachers.createTeacher(doc); | ||
|
|
||
| return teacher; |
There was a problem hiding this comment.
suggestion (code-quality): Inline variable that is immediately returned (inline-immediately-returned-variable)
Suggested change
| const teacher = await models.Teachers.createTeacher(doc); | |
| return teacher; | |
| return await models.Teachers.createTeacher(doc); | |
Explanation
Something that we often see in people's code is assigning to a result variableand then immediately returning it.
Returning the result directly shortens the code and removes an unnecessary
variable, reducing the mental load of reading the function.
Where intermediate variables can be useful is if they then get used as a
parameter or a condition, and the name can act like a comment on what the
variable represents. In the case where you're returning it from a function, the
function name is there to tell you what the result is, so the variable name
is unnecessary.
Comment on lines
+11
to
+17
| const { list, totalCount, pageInfo } = await cursorPaginate({ | ||
| model: models.Teachers, | ||
| params, | ||
| query: {}, | ||
| }); | ||
|
|
||
| return { list, totalCount, pageInfo }; |
There was a problem hiding this comment.
suggestion (code-quality): Inline variable that is immediately returned (inline-immediately-returned-variable)
Suggested change
| const { list, totalCount, pageInfo } = await cursorPaginate({ | |
| model: models.Teachers, | |
| params, | |
| query: {}, | |
| }); | |
| return { list, totalCount, pageInfo }; | |
| return await cursorPaginate({ | |
| model: models.Teachers, | |
| params, | |
| query: {}, | |
| }); | |
Explanation
Something that we often see in people's code is assigning to a result variableand then immediately returning it.
Returning the result directly shortens the code and removes an unnecessary
variable, reducing the mental load of reading the function.
Where intermediate variables can be useful is if they then get used as a
parameter or a condition, and the name can act like a comment on what the
variable represents. In the case where you're returning it from a function, the
function name is there to tell you what the result is, so the variable name
is unnecessary.
…, and teacher logic across API and UI - Updated DB definitions and models for classes and courses - Enhanced GraphQL resolvers and schemas for classes, courses, comments, and teachers - Refactored frontend UI components and hooks for classes and courses - Improved structure and consistency in data handling across modules
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed c2ae10d in 2 minutes and 27 seconds. Click for details.
- Reviewed
388lines of code in17files - Skipped
0files when reviewing. - Skipped posting
19draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. backend/plugins/education_api/src/modules/class/db/definitions/class.ts:16
- Draft comment:
The label for the 'level' field has been updated from 'level' to 'Level'. Ensure that this change is consistent with the UI expectations and other parts of the system. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%The comment is asking the PR author to ensure consistency with UI expectations and other parts of the system, which violates the rule against asking the author to ensure behavior is intended or consistent. It does not provide a specific suggestion or ask for a specific test to be written.
2. backend/plugins/education_api/src/modules/class/db/models/Classes.ts:26
- Draft comment:
Refactored createClass to directly return the Promise result. This improves readability and removes unnecessary variable assignment. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, praising a change made in the code. It doesn't provide any actionable feedback or suggestions for improvement. According to the rules, purely informative comments should be removed.
3. backend/plugins/education_api/src/modules/class/graphql/resolvers/mutations/class.ts:18
- Draft comment:
Using direct return for async operations makes the resolvers concise. Similar style is applied for the classesRemove mutation. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative and does not provide any actionable feedback or suggestions for improvement. It simply praises the use of a coding style without offering any specific advice or raising any issues.
4. backend/plugins/education_api/src/modules/comments/graphql/resolvers/mutations/comments.ts:6
- Draft comment:
Directly returning the awaited result simplifies the code. Maintaining this pattern across mutations promotes consistency. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative and does not provide any actionable feedback or suggestions for improvement. It simply praises the code for its consistency and simplicity, which does not align with the rules provided.
5. backend/plugins/education_api/src/modules/comments/graphql/resolvers/queries/comments.ts:20
- Draft comment:
The count query has been updated to filter by 'courseId' instead of passing _id directly. This correction ensures that the comment count is computed correctly. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, as it praises a change without providing any actionable feedback or suggestions. It doesn't ask for confirmation or suggest improvements, which makes it non-compliant with the rules.
6. backend/plugins/education_api/src/modules/comments/graphql/schemas/comments.ts:25
- Draft comment:
A comma was added after 'cursor: String'. This fixes potential syntax issues in the GraphQL schema definition. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, explaining that a comma was added to fix potential syntax issues. It does not suggest any changes, ask for confirmation, or point out any potential problems with the code. According to the rules, purely informative comments should be removed.
7. backend/plugins/education_api/src/modules/courses/db/models/Categories.ts:25
- Draft comment:
Renamed 'getActivityCategory' to 'getCourseCategory' to better reflect its purpose. Also, cleaning up the inline comments and using destructuring for the 'order' field increases clarity. - Reason this comment was not posted:
Comment was on unchanged code.
8. backend/plugins/education_api/src/modules/courses/db/models/Course.ts:55
- Draft comment:
In the updateCourse method, using getCourse instead of createCourse in Object.assign avoids mistakenly creating a new course. This fixes a potential bug in the update logic. - Reason this comment was not posted:
Comment looked like it was already resolved.
9. backend/plugins/education_api/src/modules/courses/graphql/resolvers/customResolvers/category.ts:12
- Draft comment:
The 'isRoot' check has been refactored to use a concise boolean expression (!category.parentId). This is clearer and achieves the same logic. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, as it praises a refactoring without providing any actionable feedback or suggestions. It doesn't align with the rules, which prohibit purely informative comments.
10. backend/plugins/education_api/src/modules/courses/graphql/resolvers/mutations/course.ts:10
- Draft comment:
Simplifying the resolver mutations by directly returning awaited values improves code consistency. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative and does not provide any actionable feedback or suggestions for improvement. It simply praises a change without offering any specific guidance or questions.
11. backend/plugins/education_api/src/modules/courses/graphql/schemas/courses.ts:59
- Draft comment:
The 'categoryId' parameter was removed from the query parameters. Ensure that client queries are updated accordingly if they relied on this parameter. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% The comment is fundamentally incorrect - it's based on a misunderstanding of the diff. The parameter was just moved within the same block, not removed. The comment suggests client updates that aren't actually needed. This could cause unnecessary work and confusion. Could there be some other context where this parameter was actually removed? Could there be a reason the parameter move is significant? No - the parameter is still in the same queryParams block and will function exactly the same way in the GraphQL schema. The order of parameters doesn't matter in GraphQL. The comment should be deleted because it's factually incorrect - the categoryId parameter was not removed, just moved within the same block.
12. backend/plugins/education_api/src/modules/teachers/graphql/resolvers/mutations/teachers.ts:6
- Draft comment:
The teacherAdd resolver now directly returns the awaited value. This maintains consistency with the other resolver patterns. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, as it praises the change without providing any actionable feedback or suggestions. It does not align with the rules, which prohibit purely informative comments.
13. backend/plugins/education_api/src/modules/teachers/graphql/schemas/teachers.ts:19
- Draft comment:
A trailing comma was added after 'cursor: String' in the query parameters to maintain consistent schema formatting. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, explaining why a trailing comma was added. It doesn't suggest any changes or ask for confirmation on the intention. According to the rules, purely informative comments should be removed.
14. frontend/plugins/education_ui/src/modules/classes/hooks/useClasses.tsx:52
- Draft comment:
The updateQuery function now uses 'courseClasses' instead of 'classCourse'. Ensure the GraphQL query and UI components are updated to match the new field name. - Reason this comment was not posted:
Comment looked like it was already resolved.
15. frontend/plugins/education_ui/src/modules/courses/components/CourseMoreColumn.tsx:14
- Draft comment:
Variable renamed from 'setRenderingContactDetail' to 'setRenderingCourseDetail' for clarity and consistency with course context. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, explaining a change that was made. It does not provide a suggestion, ask for confirmation, or point out a potential issue. According to the rules, purely informative comments should be removed.
16. frontend/plugins/education_ui/src/modules/courses/components/category/CourseCategoryRecordTable.tsx:38
- Draft comment:
Renamed the function from 'productCategoryColumns' to 'courseCategoryColumns' to more accurately represent the data being handled. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, explaining a change that was made without providing any actionable feedback or suggestions. It does not align with the rules for useful comments.
17. frontend/plugins/education_ui/src/modules/courses/detail/components/CourseDetailActions.tsx:36
- Draft comment:
Fixed typo in the action tab code: changed 'attendaces' to 'attendances'. This correction ensures proper tab identification. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, as it only describes a typo fix and its impact. It doesn't provide a suggestion or ask for confirmation on any specific change.
18. frontend/plugins/education_ui/src/modules/courses/components/category/CourseCategoryRecordTable.tsx:42
- Draft comment:
Typographical/naming inconsistency: The id "product-categories" on RecordTableTree might be outdated after switching to course-related identifiers (e.g., courseCategoryColumns). Consider renaming it to "course-categories" if this change was intended. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
19. frontend/plugins/education_ui/src/modules/courses/detail/components/CourseDetailActions.tsx:36
- Draft comment:
Typographical error fixed: the code property was changed from 'attendaces' to 'attendances'. Please ensure this change is consistent with the backend/data model. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is asking the PR author to ensure consistency with the backend/data model, which is similar to asking them to double-check or verify something. This violates the rule against asking the author to confirm or ensure things. Therefore, this comment should be removed.
Workflow ID: wflow_CzuGrgGNuVVMPgVA
You can customize
- Added backend support for students: types, DB definitions/models, GraphQL schemas, resolvers (queries, mutations, custom) - Integrated students module with existing GraphQL schema and resolvers - Implemented frontend components for student management: record table, command bar, columns, headers, etc. - Added hooks and queries for fetching and managing student data - Created StudentIndexPage for navigation and access - Refactored course module to support course deletion - Removed unused user query fragment - Updated pnpm-lock.yaml
There was a problem hiding this comment.
Caution
Changes requested ❌
Reviewed 7c4d981 in 2 minutes and 55 seconds. Click for details.
- Reviewed
1138lines of code in33files - Skipped
0files when reviewing. - Skipped posting
27draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. backend/plugins/education_api/src/apollo/resolvers/mutations.ts:5
- Draft comment:
Good aggregation of studentMutations with other domain mutations. Ensure that error handling conventions are consistently applied across all mutations. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
2. backend/plugins/education_api/src/apollo/resolvers/queries.ts:5
- Draft comment:
Student queries are properly merged. Verify that any specific error handling or logging for student queries aligns with the others. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
3. backend/plugins/education_api/src/apollo/resolvers/resolvers.ts:4
- Draft comment:
Merging student resolvers into the customResolvers object maintains consistency. Ensure that any future custom logic in studentResolvers has proper validations. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
4. backend/plugins/education_api/src/apollo/schema/schema.ts:21
- Draft comment:
Student schema types, queries, and mutations are correctly integrated. Ensure that the StudentTypes definition remains in sync with backend validations and any future schema changes. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
5. backend/plugins/education_api/src/connectionResolvers.ts:63
- Draft comment:
The Students model is registered using the 'course_students' collection name. Consider if a naming convention like 'students' might improve clarity and consistency across models. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
6. backend/plugins/education_api/src/modules/class/graphql/schemas/class.ts:24
- Draft comment:
Removal of 'studentAdd' and 'studentRemove' mutations indicates a design decision to separate student management into its own module. Ensure this change is well documented to avoid confusion. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
7. backend/plugins/education_api/src/modules/students/@types/students.ts:9
- Draft comment:
The IStudent interface marks 'password' as required, yet in the schema it is optional. Align the TypeScript types with the Mongoose schema by making 'password' optional if appropriate. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment refers to a Mongoose schema that isn't visible in the diff. Without seeing the actual schema, we can't verify if there's really a mismatch. Password fields are often required for users/students, so the current required status could be intentional. Making security-related suggestions without full context could be dangerous. The password being required could be an intentional security decision. Without seeing the Mongoose schema, we're making assumptions about the data model. The comment makes claims about a schema mismatch without providing evidence, and password requirements are often critical security decisions that shouldn't be changed without proper context. Delete this comment as it makes assumptions about schema alignment without providing evidence, and could potentially compromise security requirements if followed blindly.
8. backend/plugins/education_api/src/modules/students/db/definitions/students.ts:44
- Draft comment:
The student schema definition is clear. Ensure that the RFC 5322 compliant regex for email remains maintainable and is updated if needed in the future. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
9. backend/plugins/education_api/src/modules/students/db/models/Students.ts:24
- Draft comment:
Explicitly setting 'createdAt' in createStudent may be redundant because the schema has 'timestamps: true'. Consider removing the manual assignment to let Mongoose handle timestamps automatically. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment might be correct, but we can't verify it without seeing the schema definition. Even if timestamps are enabled, explicitly setting createdAt might be an intentional override. Without seeing the schema or understanding the full requirements, we can't be confident this change is needed. The comment could be correct - it's a reasonable suggestion about a potential redundancy. The code might benefit from following Mongoose conventions. However, we don't have strong evidence to support this change. We can't see the schema definition, and explicit timestamp setting might be intentional for this use case. Delete the comment because we lack strong evidence that timestamps are enabled in the schema, and explicit timestamp setting might be intentional.
10. backend/plugins/education_api/src/modules/students/graphql/resolvers/mutations/students.ts:4
- Draft comment:
The studentRemove mutation is straightforward. Ensure that similar error handling practices are applied as in other deletion mutations across the API. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
11. backend/plugins/education_api/src/modules/students/graphql/resolvers/queries/students.ts:11
- Draft comment:
Usage of cursorPaginate is appropriate. Consider additional query parameter validations to ensure robustness. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
12. backend/plugins/education_api/src/modules/students/graphql/schemas/students.ts:40
- Draft comment:
In the queryParams definition, ensure that delimiters (commas or whitespace) are consistent for readability. While GraphQL SDL allows optional commas, consistency improves maintainability. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
13. frontend/plugins/education_ui/src/modules/courses/Main.tsx:30
- Draft comment:
The Suspense fallback currently uses an empty. Consider using a more user-friendly loading indicator to improve UX during lazy loading. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
14. frontend/plugins/education_ui/src/modules/courses/components/CourseCommandBar.tsx:22
- Draft comment:
CourseCommandBar disables the Copy button when multiple rows are selected, which is good. No issues found here. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
15. frontend/plugins/education_ui/src/modules/courses/components/course-command-bar/CoursesDelete.tsx:16
- Draft comment:
CoursesDelete component properly handles confirmation and error toasts. Consider managing a loading state during the deletion process to provide better user feedback if the operation is slow. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
16. frontend/plugins/education_ui/src/modules/courses/graphql/mutations/removeCourses.ts:1
- Draft comment:
The REMOVE_COURSES GraphQL mutation is succinct and clear. No issues detected. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
17. frontend/plugins/education_ui/src/modules/courses/hooks/useRemoveCourses.tsx:20
- Draft comment:
The useRemoveCourses hook updates the GET_COURSES query in the Apollo cache after deletion. Ensure that this cache update logic covers all edge cases and consider adding more robust error logging if the update fails. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
18. frontend/plugins/education_ui/src/modules/students/Main.tsx:1
- Draft comment:
StudentMain correctly lazy loads the StudentIndexPage. The implementation follows the pattern used in other modules. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
19. frontend/plugins/education_ui/src/modules/students/components/StudentColumns.tsx:52
- Draft comment:
StudentColumns accesses student details (e.g., firstName, lastName). Ensure that every student record reliably includes the 'details' object to avoid potential runtime errors. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
20. frontend/plugins/education_ui/src/modules/students/components/StudentHeader.tsx:1
- Draft comment:
StudentHeader is well structured and provides clear navigation. No changes required. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
21. frontend/plugins/education_ui/src/modules/students/components/StudentRecordTable.tsx:11
- Draft comment:
StudentRecordTable integrates pagination correctly using the useStudents hook. Verify that the loading skeleton and cursor controls provide a smooth UX during data fetching. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
22. frontend/plugins/education_ui/src/modules/students/graphql/queries/getStudents.tsx:16
- Draft comment:
The GET_STUDENTS query retrieves detailed student fields. Consider omitting rarely used fields to optimize query performance if needed. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
23. frontend/plugins/education_ui/src/modules/students/hooks/useStudents.tsx:39
- Draft comment:
The useStudents hook handles pagination and merging cursor data properly. Ensure that any errors from the useQuery hook are surfaced to the UI for improved debugging. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
24. frontend/plugins/education_ui/src/modules/students/states/classDetailStates.tsx:1
- Draft comment:
The jotai atoms for student detail state are minimal and clear. No issues detected. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
25. frontend/plugins/education_ui/src/modules/students/types/type.ts:1
- Draft comment:
Student type definitions appear consistent. Verify that the structure of 'details' and other fields is uniform between the frontend and backend to prevent type mismatches. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
26. frontend/plugins/education_ui/src/pages/StudentIndexPage.tsx:1
- Draft comment:
StudentIndexPage properly composes the header and record table. Consider adding error handling or loading states if these components might fail to fetch data. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
27. frontend/plugins/education_ui/src/modules/students/components/StudentColumns.tsx:67
- Draft comment:
Typographical inconsistency: The header label for the first name column is "First name" (with lowercase 'n') while the last name column is labeled "Last Name" (with uppercase 'N'). Consider standardizing the capitalization across these headers. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is a real inconsistency, it's a very minor UI text issue. The rules state "Do NOT comment on any pure frontend UI or styling changes, only logic." This is purely a UI text styling issue that doesn't affect functionality. Additionally, it's not clear which capitalization style is the "correct" one without seeing the rest of the application's style guide. The inconsistency could potentially confuse users or indicate poor attention to detail. It would be better to have consistent styling. While consistency is good, this is too minor of a UI issue to warrant a PR comment. The rules explicitly tell us to ignore pure UI/styling changes. Delete this comment as it relates to pure UI text styling, which we're instructed to ignore.
Workflow ID: wflow_SonvzkMGU4ILpUsI
You can customize
| @@ -0,0 +1 @@ | |||
| export default {}; | |||
There was a problem hiding this comment.
This custom resolver file is currently empty. Consider adding relevant resolver logic or removing the file to avoid confusion.
| {table.getFilteredSelectedRowModel().rows.length} selected | ||
| </CommandBar.Value> | ||
| <Separator.Inline /> | ||
| <Button variant="secondary" className="bg-red-500 text-white"> |
There was a problem hiding this comment.
The Delete button in StudentCommandBar does not have an onClick handler. Implement deletion logic or integrate with a confirmation component similar to CoursesDelete.
Suggested change
| <Button variant="secondary" className="bg-red-500 text-white"> | |
| <Button variant="secondary" className="bg-red-500 text-white" onClick={() => {/* TODO: implement delete logic */}} > |
| birthDate: { type: Date, label: 'Birth date' }, | ||
| workStartedDate: { | ||
| type: Date, | ||
| label: 'Date to joined to work', |
There was a problem hiding this comment.
Typo/grammar note: The label "Date to joined to work" appears awkward. Consider rephrasing it (e.g., "Work start date" or "Date joined") to improve clarity.
Suggested change
| label: 'Date to joined to work', | |
| label: 'Work start date', |
| page: Int, | ||
| perPage: Int, | ||
| cursor: String, | ||
| direction: CURSOR_DIRECTION |
There was a problem hiding this comment.
Typo/Consistency issue: In the queryParams string, the parameter line direction: CURSOR_DIRECTION is missing a trailing comma for consistency with the other parameters.
Suggested change
| direction: CURSOR_DIRECTION | |
| direction: CURSOR_DIRECTION, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary by Sourcery
Add a new Education plugin with full-stack support for managing courses, categories, classes, teachers, and course comments.
New Features:
Enhancements:
Build:
Important
Add Education plugin with full-stack support for managing courses, categories, classes, teachers, and comments.
education_ui.education_api.Course,Category,Class,Comment,Teacher, andStudent.education_ui.education_uiandeducation_api.This description was created by
for 0971d28. You can customize this summary. It will automatically update as commits are pushed.