434aa8c69d
Phase1 后端核心：
- 新增 fsgx_v1.sql 迁移脚本（is_queue_goods/frozen_points/available_points/no_assess）
- SystemConfigServices 返佣设置扩展（周期人数/分档比例/范围/时机）
- StoreOrderCreateServices 周期循环佣金计算
- StoreOrderTakeServices 佣金发放后同步冻结积分
- StoreProductServices/StoreProduct 保存 is_queue_goods
Phase2 后端接口：
- GET /api/hjf/brokerage/progress 佣金周期进度
- GET /api/hjf/assets/overview 资产总览
- HjfPointsServices 每日 frozen_points 0.4‰ 释放定时任务
- PUT /adminapi/hjf/member/{uid}/no_assess 不考核接口
- GET /adminapi/hjf/points/release_log 积分日志接口
Phase3 前端清理：
- hjfCustom.js 路由精简（仅保留 points/log）
- hjfQueue.js/hjfMember.js API 清理/重定向至 CRMEB 原生接口
- pages.json 公排→推荐佣金/佣金记录/佣金规则
Phase4-5 前端改造：
- queue/status.vue 推荐佣金进度页整体重写
- 商品详情/订单确认/支付结果页文案与逻辑改造
- 个人中心/资产页/引导页/规则页文案改造
- HjfQueueProgress/HjfRefundNotice/HjfAssetCard 组件改造
- 推广中心嵌入佣金进度摘要
- hjfMockData.js 全量更新（公排字段→佣金字段）
Phase6 Admin 增强：
- 用户列表新增 frozen_points/available_points 列及不考核操作按钮
- hjfPoints.js USE_MOCK=false 对接真实积分日志接口
Phase7 配置文档：
- docs/fsgx-phase7-config-checklist.md 后台配置与全链路验收清单
Made-with: Cursor
3.1 KiB
Want to contribute?
If you would like to contribute, here are some notes and guidelines:
-
All new development should be on feature/fix branches, which are then merged to the
masterbranch once stable and approved; so themasterbranch is always the most up-to-date, working code -
If you are going to submit a pull request, please fork from
master, and submit your pull request back as a fix/feature branch referencing the GitHub issue number -
The code must work with all PHP versions that we support (currently PHP 7.4 to PHP 8.2).
- You can call
composer versionsto test version compatibility.
- You can call
-
Code style should be maintained.
composer stylewill identify any issues with Coding Style`.composer fixwill fix most issues with Coding Style.
-
All code changes must be validated by
composer check. -
Please include Unit Tests to verify that a bug exists, and that this PR fixes it.
-
Please include Unit Tests to show that a new Feature works as expected.
-
Please don't "bundle" several changes into a single PR; submit a PR for each discrete change/fix.
-
Remember to update documentation if necessary.
Unit Tests
When writing Unit Tests, please
- Always try to write Unit Tests for both the happy and unhappy paths.
- Put all assertions in the Test itself, not in an abstract class that the Test extends (even if this means code duplication between tests).
- Include any necessary
setup()andtearDown()in the Test itself. - If you change any global settings (such as system locale, or Compatibility Mode for Excel Function tests), make sure that you reset to the default in the
tearDown(). - Use the
ExcelErrorfunctions in assertions for Excel Error values in Excel Function implementations.
Not only does it reduce the risk of typos; but at some point in the future, ExcelError values will be an object rather than a string, and we won't then need to update all the tests. - Don't over-complicate test code by testing happy and unhappy paths in the same test.
This makes it easier to see exactly what is being tested when reviewing the PR. I want to be able to see it in the PR, not have to hunt in other unchanged classes to see what the test is doing.
How to release
- Complete CHANGELOG.md and commit
- Create an annotated tag
git tag -a 1.2.3- Tag subject must be the version number, eg:
1.2.3 - Tag body must be a copy-paste of the changelog entries.
- Push the tag with
git push --tags, GitHub Actions will create a GitHub release automatically, and the release details will automatically be sent to packagist. - Github seems to remove markdown headings in the Release Notes, so you should edit to restore these.
Note: Tagged releases are made from the
masterbranch. Only in an emergency should a tagged release be made from thereleasebranch. (i.e. cherry-picked hot-fixes.)