Rodger-Wang
|
268ce26bc9
|
services,admin: 凭据归一到 svc_config；后台服务配置菜单收敛；品牌商与公码下架
这一提交里有两条相对独立的线，落在同一批文件上（server.go / core.go / model.go /
CLAUDE.md 等被两边同时改到），按文件拆不开，故合并提交。
── 一、第三方凭据归一到 svc_config，后台「服务配置」从 11 项收敛到 6 项 ──
起因：凭据同时躺在两张扁平 key/value 表里——应用业务库的 config 与 console 库的
global_config，而合并下发时**全局那张赢**。同一个 AZURE_SPEECH_REGION /
OPENAI_API_KEY / VOLC_OPENSPEECH_APP_ID / XUNFEI 密钥在两边值不一样，运营在
「应用环境配置」里改半天没有任何效果，且不报错。global_config 还按区域整份复制
（14 区 × 31 键 = 473 行），实测其中 27 个键是各区同值。
- comm.SvcField 新增 EnvKey（后台字段表里的「下发键名」列）：非空时该字段的明文值
同时以这个名字出现在 user_getappconfig 的 env 里。已发布的客户端只读 env，
靠它继续供货、无需发新包；新客户端直接读结构化的 thirdsvcs。
- env 覆盖层与 thirdsvcs 走同一份 VIP 过滤，否则 VIP 过期的用户虽拿不到 AST 条目，
却仍能从 env 里读出同一套通话翻译凭据，那道闸门就形同虚设。
- 同作用域内 env_key 不允许重名（checkSvcEnvKeys 在保存时拦）：重名时下发结果取决于
服务 id 排序，表现为「凭据时对时不对」。
- 一次性迁移 migrate_envtosvc.go（console 每次启动跑、幂等）：基础值取中国区现值，
只有与基础值不同的区域才写 svc_region_override，473 行收敛到几十行。
顺带修了两行填错列的历史数据（group 里是键名、key 里是值），正是它让
ALIBABA_BAILIAN_APP_ID/WORKSPACE_ID 恒为 null、客户端一直用代码里写死的兜底值。
不删 global_config 的行（不可逆的线上凭据，留作回退依据），确认跑稳后由人手工 DROP。
- 后台：「第三方服务配置」改名「服务与环境配置」，「应用环境配置」并为其第二个标签页；
「全局环境配置」下线只留重定向；Agent 配置、通话翻译配置、会议记录服务三页删除
（前两者对应的 agent_config、call_translate_rule 两表在测试机与正式机上都是 0 行）。
⚠️ 会议记录服务删的只是后台入口，echomeet_orch 的数据与运行时都还在（两台机各 4 行，
是语音纪要识别/翻译/总结的服务选型来源），要换服务商现在只能直接改库。
阿龙测试环境实测：迁移前后 env 逐键比对，48/54 键值完全一致，丢失的 8 个全部是预期
丢弃（ALIBABA_OSS_* 与 COMMENT_* 无人读取、两个填错列的垃圾键名），无一个值发生变化。
验证中发现并修掉四个都不报错的坑：空值不能下发成 env 键（Dart 的 ?? 只兜 null，
空串会把默认值顶掉）、区域覆盖里的空串会把基础值抹成空、服务 enable=false 等于凭据
一个都不下发、启动时的模板补字段会给实例加空的加密字段导致误报「缺凭据」且保存被拒。
── 二、品牌商(identity=3)与公码下架 ──
brand 表、公码 authcode 及其全部后台页面与接口移除；账号作用域不再有 brandId，
设备/结算的归属改由渠道商推导。这部分不是本次会话中由 Claude 编写的。
验证：go build ./... + go vet ./... 通过，comm/console/user/echomeet/api 各包测试全绿；
admin npm run build 通过。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
4 weeks ago |
|
Rodger-Wang
|
223f7d0a44
|
deploy: 移除本机连不上的 6 台服务器，顺带清掉测试里写死的下线机器凭据
云雁(yunyan)/灵谱(lingpu) 的部署目标从所有脚本移除，ENVS / PROD_ENVS / REGIONS
现在都只剩 along。那 6 台（云雁测试/上海/日本/新加坡、灵谱测试/正式）的 SSH 私钥路径
指向的是另一台开发机，本机一台都登不上（22 端口通、无可用密钥），留在交互菜单里只会误选。
- 删 deploy/{console,admin,app}/dev-deploy.sh 的 lingpu、yunyan 两段 env_profile
- 删 deploy/{console,admin}/prod-deploy.sh 的 yunyan、lingpu 两段
- 删 deploy/app/prod-deploy.sh 的 shanghai/japan/singapore 三段 region_profile
- 删 deploy/admin/deploy.sh：早期脚本，只指向灵谱且生产位留空，已被
dev-deploy/prod-deploy 取代（CLAUDE.md 里"要同步两份 deploy.sh"也是错的，
console 那份早就不存在）
- IP 与私钥路径不再记在文档里，需要时从 git 历史取回
镜像仓库刻意保留：registry.voitrans.net / registry.lingpu.net 都在，prod-build.sh
仍可选 yunyan|lingpu 推镜像（三家仓库本机都能读写，协作者仍从他那台机部署这两家）。
顺带修掉三处把已下线机器地址连明文数据库密码一起写死的测试：
- sys/nats/nats_test.go 有个真 bug——`url := "nats://<写死地址>"` 紧接着 `if url == ""`，
常量永远不为空，所谓"默认跳过"从来没生效：每次 go test 都在连那台早已废弃的机器，
白等 4.5 秒超时。现在真正读 NATS_URL 了。
- modules/{api,echomeet}/model_test.go 的 DSN 改走 API_TEST_DSN / ECHOMEET_TEST_DSN
另外给 app/prod-deploy.sh 加了一条明确报错：输入已移除的区域名（如 shanghai）原本会被
is_tag_like 当成版本号，报出"版本指定了两次"这种驴唇不对马嘴的错。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
4 weeks ago |
|
Rodger-Wang
|
37817f2e96
|
会员与算力：VIP 管准入、算力管计量；补上线落地文档
VIP 与算力两层权益各管一件事，判定与记账统一走 comm/compute.go：
- VIP 管功能准入（无 VIP 时 user_translate / echomeet_starttask 返回 VipRequired）；
自购记 user.vipexptime，设备赋予记在 device_mac 行上（激活日 + 天数），
两者在 ResolveUserVip 合并成有效值下发，库里仍只记自购——以前绑定礼把天数
累加进用户表，解绑时拆不开。
- 算力管用量计量，按后台系数折算，先扣设备赠送再扣用户余额。
三个旧额度桶停用，存量余额由 home 启动时一次性折进 computebalance。
- 闸门 COMPUTE_GATE 默认关：user_usages 是用完才上报、没有预扣，
现在开闸门形同虚设。
另含本次「阿龙测试服 → 正式服」上线落地文档（docs/），
以及 admin 侧商品/设备/产品/用户页的配套改动。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
1 month ago |
|
Rodger-Wang
|
24e17b3434
|
收拢积压改动：恒玄 OTA、发版配置拆表、实名认证、芯片厂商/代工厂管理等
把工作区里积压的多轮改动一次性入库。主要几块：
客户端
- 恒玄 OTA 打通：新增 local_plugins/bes_ota_manager（自包含 BES SDK，
Android Java + iOS ObjC，SPP OTA 2.0），路由切到 BesOtaUpgradeView /
BesOtaUpgradeController，配套下载服务；杰理那套文件保留但已不挂路由。
- 通话翻译新增阿里 3.5 档（alibaba35_language_config.dart，
qwen3.5-livetranslate-flash-realtime + 实时声音复刻）。
- 实名认证接入、游客登录改走服务端 api_sgin 的 Tourists 分支、
功能闸门由 GuestGuard 改为 IdVerifyGuard。
- 41 个语种文案同步（OTA 新增 28 个 key 等）。
- 默认主题改为浅色，不跟随系统。
服务端
- 发版类配置拆表：app_release（版本控制 / 游客显隐，一应用一行）与
channel_app（渠道级下载地址 / 上架状态 / 支付渠道）分家，
新增 comm/apprelease.go 与 console/api_apprelease.go。
- 授权码字符串整体移除：删除 utils/license 包，新增 utils/devcode
（MAC 规范化与 PID 反解），配套迁移 SQL 在 docs/migrations/。
- console 新增芯片厂商、代工厂、用户管理接口与对应 admin 页面。
- 身份证实名核验（sys/idverify）与第三方服务的服务端专用类别。
其它
- .gitignore 补挡 apps/services/lego/sys/gin/log-*.log：gin 子系统跑起来
会按时间戳滚动生成日志（多为 0 字节），与 apps/services/comm/log 同一
性质，不进版本管理。已跟踪的 log-2026-08-20 那个仍在库里，未动。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
1 month ago |
|
Rodger-Wang
|
d7fad60658
|
设备表合表：license_<pid> 分表 → 全局 device_mac，只按 MAC 校验
设备的身份是它自己的 MAC，本来就全局唯一，定位一台设备不需要 pid。
原先按产品切分表，pid 既是查询键、又得由客户端猜出来，猜错就报
"这台 MAC 没登记在该产品下"——提示指向数据缺失，实际数据好好的。
触发改造的事故：一台已正确导入的 DEEPVOICE 耳机（MAC 在 license_b022，
产品 45090，status=0 未绑过）连不上、弹"设备连接受限"。根因是产品 45090
的 devicetype 被配成 2（BLE双端）而不是 1（经典蓝牙）：客户端
_resolveProductId 第一步就 where(devicetype==1) 把整个产品滤掉，候选只剩
Echo-one，名字互不包含 → 兜底退回 headsets.first.id = 45091，服务端拿错
pid 去 license_b023 查，自然查不到。而且就算 pid 猜对也过不去——服务端
只有 devicetype==1 才走 MAC 反查，2 会走 else 分支从空 code 反解 pid、
回退写死的 45058。
改动：
- 新增全局表 device_mac（comm.TableDeviceMac），主键 code = MAC；
productid 降为归属列，不再是查询键。TableLicense 标记废弃，只留给迁移读。
- registry.go 的 migrateLicenseToDeviceMac 每次启动跑、幂等：
① code := devicemac 修存量 → ② 按两表列名交集做 INSERT ... ON CONFLICT
DO NOTHING（不能 SELECT *：各分表建于不同时期，有的多 factoryid/probatch）
→ ③ productid 为空的用表名里的 pid 补上。孤儿分表里也是真实发出去的设备，
一并搬。搬完刻意不删旧表——不可逆数据，旧表是出问题时唯一的回退依据。
- binddevice / unbinddevice 改为先按 code 再按 MAC 全局定位，命中行的
productid 才是产品。req.Pid 不再采信。杰理链路也顺带不需要 devcode
反解 pid 了。
- 新增 comm.ScopeToProduct：合表后分表那层天然隔离没有了，每个"按产品"
的读写都必须显式带 productid，漏一处就跨产品操作——查询多列几行只是
难看，批量禁用 / 按批次删除漏掉就是删别人产品的数据。它会把调用方的
条件整体括起来，防止 "a=? or b=?" 让 or 把 productid 短路掉。
- 导入查重改成全局：同一个 MAC 出现在两个产品下会让按 MAC 反查出现歧义。
- 客户端删掉 _resolveProductId，binddevice 只报 MAC 不传 pid。
按需求明确不做应用隔离：MAC 存在即放行。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
1 month ago |
 liwei1dao
|
1639cf35a0
|
上传代码
|
2 months ago |
|
liwei1dao
|
948e368996
|
上传代码
|
2 months ago |
|
liwei1dao
|
59e54eb575
|
上传发布版本
|
2 months ago |
|
liwei1dao
|
18ffb48466
|
上传代码
|
2 months ago |
|
liwei1dao
|
e270cf89b6
|
上传新版本管理后台
|
2 months ago |
|
liwei1dao
|
6e5da54cf8
|
上传代码
|
3 months ago |
|
liwei1dao
|
a25b0c9fc0
|
上传最新的服务后台代码
|
3 months ago |
|
liwei1dao
|
197d544062
|
上传管理后台的系统升级和服务配置逻辑优化
|
3 months ago |
|
liwei1dao
|
715f8e3818
|
上传厨师版本
|
4 months ago |
