feat:RuoYi_Vue test#9
Conversation
📝 WalkthroughWalkthroughThis PR adds configuration files, code generation templates (Velocity and Vue), MyBatis mapper XMLs, internationalization resources, and Maven build metadata to the RuoYi-Vue framework, establishing infrastructure for dynamic CRUD code generation and deployment configuration. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 4 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| # 排除链接（多个用逗号分隔） | ||
| excludes: /system/notice | ||
| # 匹配链接 | ||
| urlPatterns: /system/*,/monitor/*,/tool/* |
There was a problem hiding this comment.
Build artifacts committed to version control
High Severity
The entire target/ directories for all modules (ruoyi-admin, ruoyi-common, ruoyi-framework, ruoyi-generator, ruoyi-quartz, ruoyi-system) are committed to version control. These contain compiled .class files, Maven build metadata, and duplicated configuration files. Build artifacts bloat the repository, cause merge conflicts, and expose local filesystem paths (e.g., D:\IdeaProjects\... in inputFiles.lst). A .gitignore entry for target/ is missing.
Additional Locations (2)
| # 令牌自定义标识 | ||
| header: Authorization | ||
| # 令牌密钥 | ||
| secret: abcdefghijklmnopqrstuvwxyz |
There was a problem hiding this comment.
Weak JWT secret key committed in config
High Severity
The JWT token secret is set to abcdefghijklmnopqrstuvwxyz, which is trivially guessable. An attacker who discovers or guesses this secret can forge authentication tokens, impersonate any user including administrators, and gain full unauthorized access to the system. This value is committed to version control, making it permanently discoverable in the repository history.
| master: | ||
| url: jdbc:mysql://localhost:3306/ry-vue?useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=true&serverTimezone=GMT%2B8 | ||
| username: root | ||
| password: password |
There was a problem hiding this comment.
Database credentials hardcoded and committed to repository
High Severity
Database credentials (root/password) and Druid monitoring console credentials (ruoyi/123456) are hardcoded in application-druid.yml. The statViewServlet.allow whitelist is empty, meaning the Druid monitoring endpoint at /druid/* is accessible from any IP. Combined with weak credentials, this exposes database internals and SQL monitoring data to anyone with network access.
Additional Locations (1)
|
|
||
| <update id="createTable"> | ||
| ${sql} | ||
| </update> |
There was a problem hiding this comment.
SQL injection via unparameterized string interpolation
Medium Severity
The createTable statement uses MyBatis ${sql} syntax, which performs direct string interpolation without parameterization or escaping. If the sql value is constructed from any user-influenced input (e.g., table names or columns from the code generator UI), it enables arbitrary SQL execution. This is compounded by multi-statement-allow: true in the Druid wall filter configuration, which permits stacked queries.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Note
Due to the large number of review comments, Critical severity comments were prioritized as inline comments.
🟠 Major comments (17)
RuoYi-Vue-3.9.0/ruoyi-admin/target/maven-status/maven-compiler-plugin/compile/default-compile/inputFiles.lst-1-24 (1)
1-24:⚠️ Potential issue | 🟠 MajorRemove absolute local paths from tracked files.
Line 1–Line 24expose machine-specific paths (D:\IdeaProjects\...). This leaks local environment details and makes diffs inherently non-portable. This should not be committed.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-admin/target/maven-status/maven-compiler-plugin/compile/default-compile/inputFiles.lst` around lines 1 - 24, The committed inputFiles.lst contains absolute local Windows paths (e.g., entries listing CaptchaController.java, SwaggerConfig.java, SysUserController.java, etc.) which leak environment details; remove these absolute paths by deleting this generated file from the repository and ensure the build output is not tracked (git rm --cached target/maven-status/maven-compiler-plugin/compile/default-compile/inputFiles.lst and commit), add an appropriate rule to .gitignore to exclude target/ and/or target/maven-status/, and regenerate artifacts locally or let CI produce them so only relative/source files (not generated absolute-path manifests) remain in version control.RuoYi-Vue-3.9.0/ruoyi-common/target/maven-status/maven-compiler-plugin/compile/default-compile/createdFiles.lst-1-122 (1)
1-122:⚠️ Potential issue | 🟠 MajorStop committing Maven
target/build artifacts.This file is generated output. Keeping
target/**in VCS causes noisy diffs, stale metadata, and non-reproducible reviews. Please remove trackedtargetartifacts and ignore them going forward.Suggested cleanup
+# .gitignore +**/target/- RuoYi-Vue-3.9.0/ruoyi-common/target/maven-status/maven-compiler-plugin/compile/default-compile/createdFiles.lst🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-common/target/maven-status/maven-compiler-plugin/compile/default-compile/createdFiles.lst` around lines 1 - 122, The PR includes generated Maven build artifacts (e.g., createdFiles.lst and numerous compiled class artifacts under com.ruoyi.common.*) that should not be tracked; remove these tracked build outputs, add the Maven target directory to .gitignore, and untrack existing files by running git rm --cached (or git rm -r --cached) on the generated artifacts (or target) and commit the deletion and updated .gitignore so future builds do not reintroduce these files.RuoYi-Vue-3.9.0/ruoyi-admin/target/classes/application.yml-37-37 (1)
37-37:⚠️ Potential issue | 🟠 MajorDevelopment-only settings should not be committed to the default configuration.
These settings are inappropriate for production:
- Line 37:
com.ruoyi: debug- verbose logging exposes sensitive information- Line 67:
devtools.restart.enabled: true- development hot-reload feature- Line 118:
swagger.enabled: true- API documentation endpoint exposureConsider using Spring profiles (
application-dev.yml,application-prod.yml) to separate environment-specific configurations.Also applies to: 67-67, 118-118
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-admin/target/classes/application.yml` at line 37, The default application.yml currently contains development-only settings (com.ruoyi: debug, devtools.restart.enabled: true, swagger.enabled: true); remove or neutralize these keys from the default file and move them into an environment-specific file such as application-dev.yml (set com.ruoyi: debug, devtools.restart.enabled: true, swagger.enabled: true there) while keeping production defaults in application-prod.yml (e.g., com.ruoyi: info or warn, devtools.restart.enabled: false, swagger.enabled: false); update any Spring profile activation if needed so the app uses application-dev.yml for local development and application-prod.yml for production.RuoYi-Vue-3.9.0/ruoyi-admin/target/classes/application-druid.yml-1-61 (1)
1-61:⚠️ Potential issue | 🟠 MajorBuild artifact committed to version control.
This file is located in
target/classes/, which is a Maven build output directory. Build artifacts should not be committed to version control—add**/target/to.gitignoreinstead. Committing build outputs bloats the repository and can leak environment-specific configurations.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-admin/target/classes/application-druid.yml` around lines 1 - 61, The committed build artifact RuoYi-Vue-3.9.0/ruoyi-admin/target/classes/application-druid.yml (contains spring.datasource config) should be removed from version control and the build output directory ignored: remove the file from the repo history/working tree (e.g., git rm --cached or a history rewrite if needed), add an ignore rule for **/target/ to .gitignore, and commit that change so future Maven build outputs under target/ (including target/classes/application-druid.yml) are not tracked.RuoYi-Vue-3.9.0/ruoyi-admin/target/classes/application-druid.yml-10-11 (1)
10-11:⚠️ Potential issue | 🟠 MajorSecurity risk: Hardcoded database credentials in version control.
The database credentials (
root/password) are hardcoded in this configuration file. These should be externalized using environment variables or a secrets management solution (e.g., Spring Cloud Config with Vault, or environment-specific properties files excluded from version control).- username: root - password: password + username: ${DB_USERNAME:root} + password: ${DB_PASSWORD}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-admin/target/classes/application-druid.yml` around lines 10 - 11, The application config currently hardcodes database credentials in the properties username and password fields; replace those literal values with environment/secret placeholders (e.g., use Spring property placeholders like ${DB_USERNAME} and ${DB_PASSWORD} or a Vault-backed property source) and remove the secrets from VCS, ensure the real credentials are injected at deployment via environment variables or a secrets manager, update any deployment/config docs to show the required env vars, and rotate the exposed credentials.RuoYi-Vue-3.9.0/ruoyi-admin/target/classes/application-druid.yml-44-51 (1)
44-51:⚠️ Potential issue | 🟠 MajorSecurity risk: Weak Druid console credentials and unrestricted access.
The Druid monitoring console has:
- Weak default password (
123456)- Empty
allowwhitelist, permitting access from any IP addressThis exposes sensitive database metrics and query logs to potential attackers.
🔒 Recommended security hardening
statViewServlet: enabled: true - # 设置白名单，不填则允许所有访问 - allow: + # 设置白名单，限制访问IP + allow: 127.0.0.1 url-pattern: /druid/* # 控制台管理用户名和密码 - login-username: ruoyi - login-password: 123456 + login-username: ${DRUID_USERNAME:admin} + login-password: ${DRUID_PASSWORD}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-admin/target/classes/application-druid.yml` around lines 44 - 51, The statViewServlet configuration currently uses weak default credentials (login-username: ruoyi, login-password: 123456) and an empty allow whitelist which permits unrestricted IP access; update the statViewServlet block to set a strong, non-default password for login-password (and rotate login-username if possible), populate allow with a restricted set of trusted IPs or CIDR ranges instead of leaving it blank, and consider disabling the servlet or gating it behind environment-driven toggles for non-production environments; locate the statViewServlet section and change the login-username/login-password and allow values accordingly (or wire them to secure environment variables) to close the security gap.RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/v3/index-tree.vue.vm-425-430 (1)
425-430:⚠️ Potential issue | 🟠 MajorAdd null-safety check for checkbox fields in the edit data handler.
When the API returns a checkbox field as
null, the code at line 429 throws a TypeError onsplit(",")and prevents the edit dialog from opening. The table display already uses a null-safe pattern for the same operation (line 123). Apply the same pattern here to normalize null values to empty arrays:Fix
`#foreach` ($column in $columns) `#if`($column.htmlType == "checkbox") - form.value.$column.javaField = form.value.${column.javaField}.split(",") + form.value.$column.javaField = form.value.${column.javaField} + ? form.value.${column.javaField}.split(",") + : [] `#end` `#end`🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/v3/index-tree.vue.vm` around lines 425 - 430, The edit-data handler calling get${BusinessName}(row.${pkColumn.javaField}) needs a null-safety guard for checkbox fields: in the code block that sets form.value and then assigns checkbox fields (currently doing form.value.${column.javaField}.split(",")), check whether form.value.${column.javaField} is non-null/non-empty before calling split and otherwise set the model field to an empty array; update the assignment inside the checkbox branch so form.value.${column.javaField} is normalized to an array (mirroring the null-safe pattern used in the table display).RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/index-tree.vue.vm-458-463 (1)
458-463:⚠️ Potential issue | 🟠 MajorAdd null check before calling
split()on checkbox fields.Lines 462 in the template attempts to split checkbox field values without checking if they're null. When the API returns null for optional checkbox columns, calling
.split(",")will throw an error and prevent the edit dialog from opening. Add a null check to default to an empty array when the value is empty.Proposed fix
`#foreach` ($column in $columns) `#if`($column.htmlType == "checkbox") - this.form.$column.javaField = this.form.${column.javaField}.split(",") + this.form.$column.javaField = this.form.${column.javaField} + ? this.form.${column.javaField}.split(",") + : [] `#end` `#end`The same pattern exists in the Vue 3 version (
v3/index-tree.vue.vmlines 428-432) and should be fixed identically.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/index-tree.vue.vm` around lines 458 - 463, The template is calling .split(",") on checkbox fields without null checks in the get${BusinessName}(row.${pkColumn.javaField}).then(response => { ... }) block, causing errors when the API returns null; update the assignment for each checkbox field (the lines setting this.form.${column.javaField}) to check if this.form.${column.javaField} is truthy and non-empty before splitting, otherwise set the form property to an empty array; apply the same change in the Vue 3 variant (v3/index-tree.vue.vm) for the identical assignment lines so optional checkbox values default to [] instead of calling .split on null.RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/xml/mapper.xml.vm-53-54 (1)
53-54:⚠️ Potential issue | 🟠 MajorUse an end-exclusive upper bound for generated date filters.
The Vue templates send date-only values for BETWEEN range queries. With
between #{begin} and #{end}, aDATETIME/TIMESTAMPcolumn only matches up to midnight of the end date, silently excluding all records later that day. A half-open range fixes this without changing the UI contract.💡 Proposed fix
- <if test="params.begin$AttrName != null and params.begin$AttrName != '' and params.end$AttrName != null and params.end$AttrName != ''"> and $columnName between #{params.begin$AttrName} and #{params.end$AttrName}</if> + <if test="params.begin$AttrName != null and params.begin$AttrName != '' and params.end$AttrName != null and params.end$AttrName != ''"> + and $columnName <![CDATA[ >= ]]> #{params.begin$AttrName} + and $columnName <![CDATA[ < ]]> date_add(#{params.end$AttrName}, interval 1 day) + </if>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/xml/mapper.xml.vm` around lines 53 - 54, The BETWEEN branch currently generates "and $columnName between #{params.begin$AttrName} and #{params.end$AttrName}" which yields an inclusive upper bound and misses same-day timestamps; change it to a half-open range using the begin as inclusive and end as exclusive, e.g. generate "and $columnName >= #{params.begin$AttrName} and $columnName < DATE_ADD(#{params.end$AttrName}, INTERVAL 1 DAY)" (or apply an equivalent end+1-day adjustment in the caller) so that params.begin$AttrName / params.end$AttrName and $columnName produce an end-exclusive date filter.RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/index.vue.vm-437-446 (1)
437-446:⚠️ Potential issue | 🟠 MajorSerialize BETWEEN filters for export too.
getList()is the only place that copiesdaterange*intoqueryParams.params. If a user changes a date range and exports before running search again, the export request uses stale or missingbegin*/end*filters and can return the wrong dataset.Also applies to: 595-598
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/index.vue.vm` around lines 437 - 446, The BETWEEN date-range params (the logic that copies daterange${AttrName} into this.queryParams.params) currently only runs in getList(), so export requests miss updated begin*/end* filters; extract that copying into a reusable method (e.g., syncDateRangeParams or similar) that iterates the same daterange${AttrName} -> this.queryParams.params["begin${AttrName}"]/["end${AttrName}"] assignments, call it from getList() and also from the export handler (export/exportData/handleExport) before making the export request so exports include the same BETWEEN filters as searches.RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/v3/index.vue.vm-487-495 (1)
487-495:⚠️ Potential issue | 🟠 MajorGuard nullable checkbox values before calling
split().Optional checkbox columns can come back as
null. Callingsplit(",")here throws and prevents the edit dialog from opening for those records.Proposed fix
- form.value.$column.javaField = form.value.${column.javaField}.split(",") + form.value.$column.javaField = form.value.${column.javaField} + ? form.value.${column.javaField}.split(",") + : []🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/v3/index.vue.vm` around lines 487 - 495, In handleUpdate, guard nullable checkbox fields before calling split by checking the fetched value on form.value for each checkbox column (e.g., form.value.${column.javaField}) and only call split(",") when it's a non-null/non-undefined string; otherwise set the form field to an empty array or leave it as [] so the edit dialog can open. Update the logic around get${BusinessName}(...).then(response => { form.value = response.data ... }) to replace the direct split calls for ${column.javaField} with a null-safe conditional assignment (handle inside the then callback for each checkbox-type column) so null values don't cause exceptions.RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/index.vue.vm-506-514 (1)
506-514:⚠️ Potential issue | 🟠 MajorGuard nullable checkbox values before calling
split().Optional checkbox columns can come back as
null. Callingsplit(",")here throws and prevents the edit dialog from opening for those records.Proposed fix
- this.form.$column.javaField = this.form.${column.javaField}.split(",") + this.form.$column.javaField = this.form.${column.javaField} + ? this.form.${column.javaField}.split(",") + : []🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/index.vue.vm` around lines 506 - 514, handle nullable checkbox fields returned by get${BusinessName} in handleUpdate: before calling split on each checkbox field (the occurrences of this.form.${column.javaField} inside handleUpdate), check for null/undefined and only call split(",") when a string exists; otherwise assign an empty array (or keep existing/default value) so a null value does not throw and block opening the edit dialog. Ensure the guard is applied for every checkbox-mapped property set in handleUpdate (the template block handling $column.htmlType == "checkbox").RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/v3/index.vue.vm-411-420 (1)
411-420:⚠️ Potential issue | 🟠 MajorFix the BETWEEN datetime parameter guard to check
ref.valueinstead of the ref object itself.The guard condition
if (null != daterange${AttrName} && '' != daterange${AttrName})checks the ref object directly, which is always truthy. This means the condition always enters and can write empty arrays to the params. Usedaterange${AttrName}.valuein the condition and extract this BETWEEN param-building logic into a reusable function for bothgetList()andhandleExport()to prevent filter divergence between the UI display and exports.Also applies to: 583-586
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/v3/index.vue.vm` around lines 411 - 420, The BETWEEN datetime guard currently checks the ref object (daterange${AttrName}) which is always truthy; update the condition to test the ref's value (e.g., daterange${AttrName}.value != null && daterange${AttrName}.value !== '' && daterange${AttrName}.value.length) and only then set queryParams.value.params["begin${AttrName}"] and ["end${AttrName}"]; extract this BETWEEN param-building block into a shared helper (callable from getList() and handleExport()) so both flows use the same logic and avoid filter divergence between UI display and exports.RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/index.vue.vm-208-210 (1)
208-210:⚠️ Potential issue | 🟠 MajorAdd
propto editor fields so validation can run.The template generates validation rules for required columns (line 420), but the editor field on line 209 never binds them because it lacks the
prop="${field}"attribute. All other field types (input, imageUpload, fileUpload, select) include this attribute. Required editor fields will therefore submit empty without triggering validation.Proposed fix
- <el-form-item label="${comment}"> + <el-form-item label="${comment}" prop="${field}"> <editor v-model="form.${field}" :min-height="192"/> </el-form-item>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/index.vue.vm` around lines 208 - 210, The editor field lacks a prop binding so form validation rules aren't applied; update the generated template for the editor component (the <editor v-model="form.${field}" .../> line) to include prop="${field}" (matching how other inputs bind el-form validation) so the required rules generated for this column are associated with the editor field and validation will run.RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/v3/index.vue.vm-191-193 (1)
191-193:⚠️ Potential issue | 🟠 MajorAdd
propto editor fields for form validation to work.The template generates validation rules for required columns, but this
el-form-itemnever binds them. Editor fields lack thepropattribute that Element Plus requires to link form items to validation rules. All other field types (input, imageUpload, fileUpload, select, checkbox) consistently includeprop="${field}", making this an unintended gap. Required editor fields will submit empty without validation errors.Proposed fix
`#elseif`($column.htmlType == "editor") - <el-form-item label="${comment}"> + <el-form-item label="${comment}" prop="${field}"> <editor v-model="form.${field}" :min-height="192"/> </el-form-item>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/v3/index.vue.vm` around lines 191 - 193, The el-form-item for rich text editor fields is missing the prop binding so validation rules aren't applied; update the editor block (the el-form-item that wraps <editor v-model="form.${field}" ...>) to include prop="${field}" so it matches other fields (e.g., input/imageUpload/select) and links the generated validation rules to the editor's v-model value.RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/v3/index.vue.vm-309-318 (1)
309-318:⚠️ Potential issue | 🟠 MajorApply type coercion to dict values in sub-table selectors.
The main-form branches conditionally apply
parseInt()forInteger/Longdict types (lines 195, 233), but the sub-table branch (line 309) always binds strings. This causes numeric dict values to fail rendering as selected when editing existing rows, and creates payload type inconsistency.Proposed fix
<el-option v-for="dict in $column.dictType" :key="dict.value" :label="dict.label" - :value="dict.value" +#if($column.javaType == "Integer" || $column.javaType == "Long") + :value="parseInt(dict.value)" +#else + :value="dict.value" +#end ></el-option>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/v3/index.vue.vm` around lines 309 - 318, The sub-table selector in the el-table-column (template using scope.row.$javaField and iterating $column.dictType) always binds dict values as strings, causing numeric dicts to mismatch; update the el-option value binding so it coerces dict.value to a number when the column's Java type is Integer or Long (mirror the parseInt behavior used in the main-form branches around the parseInt usages), e.g., use a conditional that parses/coerces dict.value to a Number for $column.javaType == "Integer" or "Long" and leaves it as a string otherwise so scope.row.$javaField and option values share the same type.RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/index.vue.vm-321-330 (1)
321-330:⚠️ Potential issue | 🟠 MajorAdd type coercion for numeric dict values in sub-table editors to match main-form behavior.
The main-form
selectandradiobranches conditionally parse Integer/Long dict values usingparseInt, but the sub-table branch (lines 321-333) always binds raw string values. This causes inconsistent type handling and can prevent numeric selections from rendering as selected during editing.Proposed fix
<el-option v-for="dict in dict.type.$column.dictType" :key="dict.value" :label="dict.label" - :value="dict.value" +#if($column.javaType == "Integer" || $column.javaType == "Long") + :value="parseInt(dict.value)" +#else + :value="dict.value" +#end ></el-option>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/index.vue.vm` around lines 321 - 330, The sub-table editor (the el-table-column template using v-model="scope.row.$javaField" and iterating dict.type.$column.dictType) currently binds dict option values as raw strings; update the el-option :value binding to coerce numeric dict values to the same types used in main-form select/radio branches (use parseInt or Number for Integer/Long dictType) so scope.row.$javaField receives a numeric value when appropriate and selection rendering/editing is consistent with the main form.
🟡 Minor comments (5)
RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/mapper/generator/GenTableColumnMapper.xml-1-127 (1)
1-127:⚠️ Potential issue | 🟡 MinorBuild artifact should not be committed.
This mapper XML is located in
target/classes/. The source file insrc/main/resources/should be tracked instead. Add**/target/to.gitignore.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/mapper/generator/GenTableColumnMapper.xml` around lines 1 - 127, The committed build artifact GenTableColumnMapper.xml under the target/classes mapper (namespace="com.ruoyi.generator.mapper.GenTableColumnMapper") must be removed from version control and the build output ignored: add the pattern **/target/ (or target/) to .gitignore, remove the file from the index (git rm --cached target/classes/mapper/generator/GenTableColumnMapper.xml or git rm -r --cached target/), and ensure the canonical source mapper under src/main/resources (the original GenTableColumnMapper.xml) is present and committed instead; commit the .gitignore change and the removal so future builds won't track target/*.RuoYi-Vue-3.9.0/ruoyi-common/target/maven-status/maven-compiler-plugin/compile/default-compile/inputFiles.lst-1-107 (1)
1-107:⚠️ Potential issue | 🟡 MinorBuild metadata should not be committed to version control.
This file is Maven compiler plugin metadata located in
target/maven-status/. It contains absolute paths from a developer's local machine (D:\IdeaProjects\...), which:
- Exposes local file system structure
- Is machine-specific and not portable
- Bloats the repository with regenerable build artifacts
Add
**/target/to.gitignoreto exclude all build outputs.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-common/target/maven-status/maven-compiler-plugin/compile/default-compile/inputFiles.lst` around lines 1 - 107, The committed Maven build metadata (target/maven-status/.../inputFiles.lst) exposes local absolute paths and should not be in VCS; add a rule like **/target/ to .gitignore, remove the tracked file(s) from the index (unstage/remove them from Git while keeping them locally), and commit the .gitignore change and the removal so future Maven builds (which regenerate target/maven-status) are ignored; specifically target the path shown (RuoYi-Vue-3.9.0/ruoyi-common/target/maven-status/maven-compiler-plugin/compile/default-compile/inputFiles.lst) when removing tracked artifacts and then rebuild to ensure no needed sources are lost.RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/java/sub-domain.java.vm-1-76 (1)
1-76:⚠️ Potential issue | 🟡 MinorBuild artifact in
target/classes/.This template file is a build output. The source template in
src/main/resources/vm/java/should be tracked instead.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/java/sub-domain.java.vm` around lines 1 - 76, The file ruoyi-generator/target/classes/vm/java/sub-domain.java.vm is a generated build artifact and should be removed from the commit; delete this file from the repo (do not edit it) and add/ensure target/ or target/classes is ignored in .gitignore so generated files are not tracked, then commit the deletion; ensure the actual source template src/main/resources/vm/java/sub-domain.java.vm is present and tracked instead and re-run the build to verify only source templates (not target artifacts) are changed in this PR.RuoYi-Vue-3.9.0/ruoyi-quartz/target/classes/mapper/quartz/SysJobMapper.xml-1-111 (1)
1-111:⚠️ Potential issue | 🟡 MinorBuild artifact should not be committed.
This mapper XML is in
target/classes/. Track the source file insrc/main/resources/instead and add**/target/to.gitignore.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-quartz/target/classes/mapper/quartz/SysJobMapper.xml` around lines 1 - 111, The PR accidentally committed a generated mapper XML for SysJobMapper (contains resultMap id="SysJobResult" and sql id="selectJobVo") from the build output; remove that generated file from the repo (git rm --cached the committed mapper), restore/commit the original source mapper (the SysJobMapper.xml under your resources source tree) and update .gitignore to include the build output directory pattern (e.g. **/target/) so future compiled resources aren’t tracked.RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/v3/index-tree.vue.vm-337-340 (1)
337-340:⚠️ Potential issue | 🟡 MinorCheck the ref's
.valuebefore adding begin/end params.
daterange${AttrName}is a Vue ref initialized withref([]), so the conditionif (null != daterange${AttrName} && '' != daterange${AttrName})is always true—it checks the ref object itself, not the array inside it. This causes the code to write undefined values toqueryParamseven when no date range is selected. Guard ondaterange${AttrName}.value.lengthinstead.💡 Proposed fix
- if (null != daterange${AttrName} && '' != daterange${AttrName}) { + if (Array.isArray(daterange${AttrName}.value) && daterange${AttrName}.value.length === 2) { queryParams.value.params["begin${AttrName}"] = daterange${AttrName}.value[0] queryParams.value.params["end${AttrName}"] = daterange${AttrName}.value[1] }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/vue/v3/index-tree.vue.vm` around lines 337 - 340, The current check inspects the ref object daterange${AttrName} rather than its inner array, so begin${AttrName}/end${AttrName} can be set to undefined; change the guard to verify the ref's value array (e.g., daterange${AttrName}.value && daterange${AttrName}.value.length >= 2) before assigning queryParams.value.params["begin${AttrName}"] and queryParams.value.params["end${AttrName}"], ensuring you read daterange${AttrName}.value[0] and .value[1] only when the array contains both entries.
🧹 Nitpick comments (8)
RuoYi-Vue-3.9.0/.idea/.gitignore (1)
1-10: LGTM! Standard IDEA ignore patterns are correctly configured.The file appropriately excludes user-specific and environment-dependent IntelliJ IDEA artifacts from version control. The patterns are syntactically correct and cover the essential files.
Optionally, you may consider adding a few more common IDEA patterns for completeness:
📋 Optional additional patterns
# Datasource local storage ignored files /dataSources/ /dataSources.local.xml +# Task management +/tasks.xml +# User dictionaries +/dictionaries/ +# Code coverage and analysis +/sonarlint/ +/usage.statistics.xml🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/.idea/.gitignore` around lines 1 - 10, The .gitignore currently contains standard IDEA patterns and is fine; optionally expand it by adding common IntelliJ exclusions such as .idea/, *.iml, out/, and workspace.xml to cover more IDE artifacts—update the .gitignore file (the existing entries like /shelf/, /workspace.xml, /httpRequests/, /mavenHomeManager.xml, /dataSources/, /dataSources.local.xml) to include these additional patterns so all user-specific and build artifacts are consistently ignored.RuoYi-Vue-3.9.0/ruoyi-admin/target/classes/logback.xml (1)
4-4: Hardcoded log path reduces portability.The path
/home/ruoyi/logswon't work on Windows and assumes a specific user directory structure. Consider using a relative path or environment variable:<property name="log.path" value="${LOG_PATH:-./logs}" />🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-admin/target/classes/logback.xml` at line 4, The logback property "log.path" is hardcoded to "/home/ruoyi/logs", which breaks portability (e.g., Windows); change the property definition for log.path to accept an environment variable or default to a relative directory (for example using a placeholder like ${LOG_PATH:-./logs}) so the application can run across platforms; update the <property name="log.path"> entry (symbol: log.path) to read from the environment or fallback to ./logs and ensure any references to log.path continue to work.RuoYi-Vue-3.9.0/ruoyi-generator/target/maven-status/maven-compiler-plugin/compile/default-compile/createdFiles.lst (1)
1-13: Build artifacts should not be committed to version control.This file is auto-generated by Maven under the
target/directory. Committing build outputs bloats the repository and can cause merge conflicts. Add**/target/to.gitignoreand remove these files from the repository.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/maven-status/maven-compiler-plugin/compile/default-compile/createdFiles.lst` around lines 1 - 13, The commit includes Maven build artifacts (e.g., createdFiles.lst and compiled classes like GenTable.class, GenTableColumn.class, GenTableServiceImpl.class, GenTableMapper.class, GenTableColumnMapper.class, VelocityUtils.class, VelocityInitializer.class) under target/ which must not be tracked; remove these files from the repository (unstage/remove tracked build outputs such as the createdFiles.lst and all files under target/), add an entry /**/target/ or simply /target/ to .gitignore to prevent re-adding, and commit the changes (use git rm --cached or equivalent to stop tracking without deleting local build files). Ensure only source files remain tracked and verify no other target/ artifacts are present before pushing.RuoYi-Vue-3.9.0/ruoyi-admin/target/classes/i18n/messages.properties (1)
1-38: Build artifact undertarget/should not be committed.This i18n resource file is located under
target/classes/, which is a Maven build output directory. The source file should exist undersrc/main/resources/i18n/messages.propertiesand be copied totarget/during build. Removetarget/contents from version control.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-admin/target/classes/i18n/messages.properties` around lines 1 - 38, The committed file messages.properties is a Maven build artifact under target/classes and must be removed from version control; delete the tracked copy (git rm --cached target/classes/i18n/messages.properties or remove the entire target/ directory from tracking), add target/ to .gitignore to prevent future commits, and ensure the real source messages.properties lives in your resources source tree (src/main/resources/i18n/messages.properties) so it will be copied into target during the build.RuoYi-Vue-3.9.0/ruoyi-admin/target/classes/application.yml (1)
1-129: Build artifact undertarget/should not be committed.This configuration file is under
target/classes/. The source should be atsrc/main/resources/application.yml. Additionally, the static analysis tool flagged incorrect line endings (CRLF instead of LF).RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/sql/sql.vm (1)
1-22: Build artifact undertarget/should be removed from version control.This Velocity template is under
target/classes/, which is populated during the Maven build. The source should reside insrc/main/resources/vm/sql/sql.vm.The permission structure (
:listfor menu,:queryfor button) is consistent with the controller template pattern.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/sql/sql.vm` around lines 1 - 22, The checked-in generated template sql.vm lives in the build output (under target) and should be removed from version control; delete the generated sql.vm from the repository, restore or add the canonical template into the project resource source (the vm SQL template used to generate these inserts, i.e. the source sql.vm), and add the build output (target) to .gitignore so future generated files (the sys_menu INSERT blocks and permission strings like '${permissionPrefix}:list' and '${permissionPrefix}:query') are not committed.RuoYi-Vue-3.9.0/ruoyi-quartz/target/classes/mapper/quartz/SysJobMapper.xml (1)
23-26: SQL fragment excludesupdate_byandupdate_timecolumns.The
selectJobVofragment doesn't includeupdate_byandupdate_timecolumns, but theSysJobResultresultMap maps them (lines 18-19). Queries using this fragment will return null for these properties. If this is intentional, consider adding a comment; otherwise, add the columns:<sql id="selectJobVo"> - select job_id, job_name, job_group, invoke_target, cron_expression, misfire_policy, concurrent, status, create_by, create_time, remark + select job_id, job_name, job_group, invoke_target, cron_expression, misfire_policy, concurrent, status, create_by, create_time, update_by, update_time, remark from sys_job </sql>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-quartz/target/classes/mapper/quartz/SysJobMapper.xml` around lines 23 - 26, The selectJobVo SQL fragment is missing the update_by and update_time columns that the SysJobResult resultMap expects; update the <sql id="selectJobVo"> fragment to include the update_by and update_time columns in the select list (or add an inline comment stating omission is intentional) so queries return values for the SysJobResult.updateBy and SysJobResult.updateTime fields; locate the selectJobVo fragment and add "update_by, update_time" to the selected columns.RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/mapper/generator/GenTableColumnMapper.xml (1)
43-46: Consider usingANDinstead of&&for SQL portability.Line 43 uses
&&as the logical AND operator inside the CDATA section. While MySQL supports this, it's non-standard SQL. UsingANDimproves portability and readability.- select column_name, (case when (is_nullable = 'no' <![CDATA[ && ]]> column_key != 'PRI') then '1' else '0' end) as is_required, ... + select column_name, (case when (is_nullable = 'no' AND column_key != 'PRI') then '1' else '0' end) as is_required, ...🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/mapper/generator/GenTableColumnMapper.xml` around lines 43 - 46, The SQL CASE in GenTableColumnMapper.xml's select (the expression computing is_required in the select list of the GenTableColumnMapper.xml <select>) uses '&&' for logical AND; replace the non-standard '&&' with the SQL-standard 'AND' in the CASE WHEN condition (the clause checking is_nullable = 'no' && column_key != 'PRI') so it reads is_nullable = 'no' AND column_key != 'PRI' to improve portability and readability.
| # 令牌自定义标识 | ||
| header: Authorization | ||
| # 令牌密钥 | ||
| secret: abcdefghijklmnopqrstuvwxyz |
There was a problem hiding this comment.
Critical: Hardcoded JWT secret is a severe security vulnerability.
The token secret abcdefghijklmnopqrstuvwxyz is weak, predictable, and exposed in version control. An attacker can forge valid JWT tokens to impersonate any user, including administrators.
Use environment variables or external secrets management:
token:
secret: ${TOKEN_SECRET}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@RuoYi-Vue-3.9.0/ruoyi-admin/target/classes/application.yml` at line 96, The
JWT secret is hardcoded as the plain string under the secret key in
application.yml (token.secret) which is insecure; replace the literal with an
environment-backed value (e.g., reference an env var like TOKEN_SECRET) or pull
from your secrets manager and update the configuration consumer (any code
reading token.secret) to expect a runtime-provided secret instead of a
checked-in string, and ensure deployment injects a strong random secret and
rotates it via your CI/CD or secret store.
| <root level="info"> | ||
| <appender-ref ref="console" /> | ||
| </root> | ||
|
|
||
| <!--系统操作日志--> | ||
| <root level="info"> | ||
| <appender-ref ref="file_info" /> | ||
| <appender-ref ref="file_error" /> | ||
| </root> |
There was a problem hiding this comment.
Invalid configuration: Multiple <root> elements defined.
Logback allows only one <root> element. The second definition (Lines 84-87) will override the first (Lines 79-81), causing the console appender to be ignored. Merge them into a single <root>:
🐛 Proposed fix
- <root level="info">
- <appender-ref ref="console" />
- </root>
-
- <!--系统操作日志-->
- <root level="info">
- <appender-ref ref="file_info" />
- <appender-ref ref="file_error" />
- </root>
+ <root level="info">
+ <appender-ref ref="console" />
+ <appender-ref ref="file_info" />
+ <appender-ref ref="file_error" />
+ </root>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <root level="info"> | |
| <appender-ref ref="console" /> | |
| </root> | |
| <!--系统操作日志--> | |
| <root level="info"> | |
| <appender-ref ref="file_info" /> | |
| <appender-ref ref="file_error" /> | |
| </root> | |
| <root level="info"> | |
| <appender-ref ref="console" /> | |
| <appender-ref ref="file_info" /> | |
| <appender-ref ref="file_error" /> | |
| </root> |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@RuoYi-Vue-3.9.0/ruoyi-admin/target/classes/logback.xml` around lines 79 - 87,
There are two <root> elements which is invalid; merge them into a single root
element so all appenders are registered. Update the XML to have one <root
level="info"> that contains <appender-ref ref="console"/>, <appender-ref
ref="file_info"/>, and <appender-ref ref="file_error"/>; remove the duplicate
<root> block. Ensure the combined root preserves level="info" and includes the
console, file_info and file_error appenders so none are dropped.
| <update id="createTable"> | ||
| ${sql} | ||
| </update> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Inspect every createTable call path to confirm what can reach this raw SQL sink.
rg -n -C3 '\bcreateTable\s*\('Repository: Achillesed/CodeRabbit-Test
Length of output: 52
🏁 Script executed:
# Check if the file exists in the repository
find . -name "GenTableMapper.xml" -type f 2>/dev/null | head -20Repository: Achillesed/CodeRabbit-Test
Length of output: 154
🏁 Script executed:
# Search for GenTableMapper references in Java source files
rg -t java "GenTableMapper|createTable" --max-count 20Repository: Achillesed/CodeRabbit-Test
Length of output: 52
🏁 Script executed:
# Look for any mapper XML files and understand the structure
fd -e xml -p "mapper" | grep -i gen | head -20Repository: Achillesed/CodeRabbit-Test
Length of output: 241
🏁 Script executed:
# Search for how the sql parameter might be constructed in the codebase
rg -t java "createTable|GenTable" -A 5 -B 5 | head -100Repository: Achillesed/CodeRabbit-Test
Length of output: 52
🏁 Script executed:
# Read the GenTableMapper.xml file to see the full context
cat -n RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/mapper/generator/GenTableMapper.xml | head -200Repository: Achillesed/CodeRabbit-Test
Length of output: 14026
🏁 Script executed:
# Check if there's source code for this module
find RuoYi-Vue-3.9.0/ruoyi-generator -name "*.java" -type f 2>/dev/null | head -20Repository: Achillesed/CodeRabbit-Test
Length of output: 52
🏁 Script executed:
# Look for the source version of the mapper file
find RuoYi-Vue-3.9.0 -name "GenTableMapper.xml" -type f 2>/dev/nullRepository: Achillesed/CodeRabbit-Test
Length of output: 152
Replace raw ${sql} with parameterized DDL construction.
The <update> statement uses ${sql} for literal text substitution. This is a SQL injection risk even in a code generator context. MyBatis ${} bypasses parameter binding, so any validation defects upstream become database execution vulnerabilities. Move DDL construction, validation, and allowlisting into service code, passing only verified CREATE TABLE statements to the mapper. Use a safe DDL builder or stored procedure if dynamic table creation is required.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/mapper/generator/GenTableMapper.xml`
around lines 174 - 176, The mapper's <update id="createTable"> is using raw
`${sql}` which performs literal substitution and allows SQL injection; replace
this by removing `${sql}` from GenTableMapper.xml and instead accept a single
validated parameter (e.g., a named parameter like "ddl" or a stored-proc call)
from service code: move DDL construction, validation and allowlisting into the
generator/service layer (the code that calls GenTableMapper.createTable) and
pass only a safe, validated DDL string or invoke a stored procedure via a fixed
mapper method; ensure the service uses a DDL builder or explicit whitelist of
allowed identifiers before calling the mapper and update any calling code to use
the new parameterized mapper method instead of supplying raw `${sql}`.
| int rows = ${className}Mapper.insert${ClassName}(${className}); | ||
| insert${subClassName}(${className}); | ||
| return rows; |
There was a problem hiding this comment.
Only sync child rows after the parent write succeeds.
Both paths mutate the subtable without checking whether the parent insert/update actually affected a row. A 0-row parent write will still commit these child mutations and can leave orphaned or stale sub-records.
Proposed fix
`#if`($table.sub)
int rows = ${className}Mapper.insert${ClassName}(${className});
- insert${subClassName}(${className});
+ if (rows > 0)
+ {
+ insert${subClassName}(${className});
+ }
return rows;
`#else`
return ${className}Mapper.insert${ClassName}(${className});
`#end` `#if`($table.sub)
- ${className}Mapper.delete${subClassName}By${subTableFkClassName}(${className}.get${pkColumn.capJavaField}());
- insert${subClassName}(${className});
-#end
- return ${className}Mapper.update${ClassName}(${className});
+ int rows = ${className}Mapper.update${ClassName}(${className});
+ if (rows > 0)
+ {
+ ${className}Mapper.delete${subClassName}By${subTableFkClassName}(${className}.get${pkColumn.capJavaField}());
+ insert${subClassName}(${className});
+ }
+ return rows;
+#else
+ return ${className}Mapper.update${ClassName}(${className});
`#end`Also applies to: 101-105
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/java/serviceImpl.java.vm`
around lines 76 - 78, The child-table write is being executed unconditionally;
change the logic so that after calling
${className}Mapper.insert${ClassName}(${className}) you check the returned int
rows and only call insert${subClassName}(${className}) when rows > 0 (same for
the update path referenced around lines 101-105: only call the subtable mutation
helper when the parent update returned a positive rows count). Update the
methods using ${className}Mapper.insert${ClassName} and the corresponding update
call to gate insert${subClassName}/${subClassUpdateMethod} on rows > 0 to avoid
creating orphaned child rows.
| #elseif($column.javaType == 'Date') | ||
| @JsonFormat(pattern = "yyyy-MM-dd") | ||
| @Excel(name = "${comment}", width = 30, dateFormat = "yyyy-MM-dd") |
There was a problem hiding this comment.
Missing @JsonFormat import will cause compilation errors.
The template uses @JsonFormat annotation for Date fields (line 34), but the corresponding import statement is not included. When a sub-entity has Date fields, the generated code will fail to compile.
🐛 Proposed fix
`#foreach` ($import in $subImportList)
import ${import};
`#end`
+import com.fasterxml.jackson.annotation.JsonFormat;
import org.apache.commons.lang3.builder.ToStringBuilder;Alternatively, ensure com.fasterxml.jackson.annotation.JsonFormat is added to $subImportList when Date columns with list=true are present.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@RuoYi-Vue-3.9.0/ruoyi-generator/target/classes/vm/java/sub-domain.java.vm`
around lines 33 - 35, The template uses the `@JsonFormat` annotation for Date
fields but does not add the corresponding import, causing compilation failures;
update the sub-domain template (where $column.javaType == 'Date' is handled) to
ensure the import com.fasterxml.jackson.annotation.JsonFormat is emitted—either
add that import unconditionally in the template imports section or, better, add
logic to include com.fasterxml.jackson.annotation.JsonFormat into $subImportList
whenever a Date column (i.e., $column.javaType == 'Date') is present (and
particularly when list=true) so generated classes always have the required
import.
1 participant
Note
Medium Risk
Mainly adds generated
target/build outputs and.ideametadata, which is low functional risk but can bloat the repo and accidentally ship environment-specific config (including database credentials) into version control.Overview
This PR primarily checks in generated artifacts: IntelliJ
.ideafiles plus large amounts of Maventarget/output (compiled classes,maven-statuslists, and packaged resource copies likeapplication.yml,logback.xml, MyBatis mapper XMLs, and generator Velocity templates).No source-level feature work is evident in the diff; the main impact is repository hygiene and the risk of committing environment-specific runtime configuration from
target/classes.Written by Cursor Bugbot for commit ef559f0. This will update automatically on new commits. Configure here.
Summary by CodeRabbit
Release Notes
New Features
Configuration & Infrastructure