laoyang/SyncCalendar
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity
117 Commits 1 Branch 11 Tags
8126c058fa275da9ce5bd4fb986a6b3c25a9c158
Commit Graph
10 Commits
Author SHA1 Message Date
laoyang 8126c058fa diag(同步): 抽出 reportRaw 通用执行器，排查 Inbox 待办拉不到 (#53) 
## 排查过程与结论

用户反馈：在 Inbox 新建待办后，列表里看不到。

### 诊断手段
把 `reportComponents` 的 HTTP 执行部分抽成 `reportRaw`，
新增 `reportAll`（不带 comp-filter 的全量 calendar-query）作为对照。

### 关键数据
| 查询 | 结果 |
|---|---|
| Inbox 的 VTODO REPORT | 响应 68 字符，含VTODO=false，响应数=0 |
| Inbox 的全量 REPORT | **722 个资源，全部 VEVENT=true** |
| 娱乐(home) 的 REPORT | **722 个资源** ← 与上面数字完全相同 |
| 待办创建 PUT | `home_todo/todo-1793849023185-qx4b36.ics` → **201 成功** |

### 结论
**群晖把 `home_todo` 解析成了 `home` 的别名**，两个 URL 返回同一份 722 条日程数据。
所以：
1. 待办 PUT 到 `home_todo/todo-xxx.ics`，实际写进了 home 本
2. 按 VTODO 过滤查 `home_todo` → 服务器在这个"别名本"里找不到 VTODO → 返回空
3. 待办永远同步不下来

这不是 App 的 bug，是**服务器端日历本配置问题**（Inbox 指向了错误的存储）。

## 本次改动
- `reportComponents` 拆出 `reportRaw(href, auth, body, compName)`
- 新增 `reportAll(href, auth)`：全量 calendar-query
- 移除临时诊断日志

## 待用户处理
需要在群晖 Calendar Server 后台检查 `home_todo` 这个日历本的真实路径，
或让用户改用其他待办本（如「个人成长」已验证可正常工作）。

## 编译
BUILD SUCCESSFUL
 2026-11-05 11:26:37 +08:00
laoyang daa577e88e feat(待办/日程): 两页时间选择器统一居中弹出 + 待办截止行去掉「修改」字样 (#51) 
## 1. 日程页时间选择器也改为居中弹出
用户要求：「新建日程那里，开始和结束时间也用这种方式弹出来吧」

与待办页保持一致：根节点改 Stack，弹层居中浮在内容之上。
移除 bindSheet（SDK 的 SheetOptions 没有 position/alignment，只能底部弹）。
三种弹层（时间选择/重复范围/重复截止）继续共用同一个 sheetMode 切换。

### 真机验证（5NC0225B27004718）
弹层 y=713~1691，中心 1202；屏幕中心 1222，偏差 20px ✅

## 2. 待办页截止时间行去掉「修改」二字
用户要求：「修改那两个字没必要，直接点那个时间框，出现选择时间的地方」

整行本来就可点，右侧改为一个 `›` 箭头作视觉暗示（与日程页「开始/结束时间」行一致）。

## 3. 修复：纯待办本的 event 通道误落库（导致 Inbox 待办消失 + 编辑报错）

### 根因
`SyncEngine` 的 event 通道用 `DavClient.reportEtags(href)`，**不区分本的 COMP_SET 类型**。
对纯待办本（如群晖 Inbox，COMP_SET=todo）也照常跑 event REPORT：
- 服务器返回了文件列表（里面其实是 VTODO 文件）
- `parseEvents` 解析出 0 条日程，**但文件仍被落库成 kind='event'**
- 结果：本地库出现"属于待办本的日程记录"（实测 id=748 title=Hvf）
- 用户新建的「测试」待办进不来，反而被这条假日程占用 cal_key

### 后果
- 待办列表看不到（列表只查 kind='todo'）
- 点它编辑走日程通道 → 报「需要联网 + 日历本需可写」
- 用户反馈的「编辑待办失败」由此而来

### 修法
event 通道前判断 `acc.calendarComps[i] === 'todo'` 就跳过，
日志明确输出「是纯待办本(COMP_SET=todo)，跳过 event 通道」。

### 验证
日志实测：`日历本[1]「Inbox」是纯待办本(COMP_SET=todo)，跳过 event 通道` ✅

## 编译
BUILD SUCCESSFUL

## 遗留
Inbox 的 VTODO REPORT 在群晖上仍返回空 multistatus（68 字符），
「测试」待办能否同步需用户重新建一条再验证。
 2026-11-05 11:14:46 +08:00
laoyang 09cb0f9664 feat(账号/待办): 日历本区分日历与待办类型，待办标签两级判定 #6 
用户要求两点：
1. 添加/修改账号时，在颜色前面显示图标区分「日历本 / 待办本」
2. 没勾选任何待办本 → 待办标签不显示；选了待办本但没数据 → 也不显示

## 协议层：supported-calendar-component-set
CalDAV 用这个属性声明集合支持哪些组件：
    <C:supported-calendar-component-set>
      <C:comp name="VEVENT"/>   ← 纯日历本
      <C:comp name="VTODO"/>    ← 纯待办本
    </C:supported-calendar-component-set>

DavClient 改动：
- PROPFIND 请求加该属性（两处：propfindColors / propfindCalendars）
- 新增 `parseComps()` 归一成四类：event / todo / both / **unknown**
- `DavColorEntry` 与 `DavCalendarEntry` 都加 comps 字段

⭐ 为什么保留 unknown：
   很多服务器（含自研实现）压根不返回这个属性。若武断判成"不是待办本"，
   用户原本能用的日历会被错误分类。unknown 一律按**日历**对待，保持兼容。

## 存储
DavAccount 增加 `calendarComps: string[]`，与 calendarHrefs 一一对应。
JSON 存储天然支持；旧数据读出来是空数组 → 全部 unknown → 视为日历。

## 界面
EditCalendarRow 在颜色圆点**前面**加类型图标，用户先看类型再看颜色：
  · 待办本 → ✓ 配成功色
  · 混合本 → ▦✓
  · 日历/unknown → ▦

## 待办标签两级判定
1. `hasTodoBook()`：被选中的日历本里存在 comps 为 todo/both 的
   —— 一个都没选 ⇒ 必然没待办，直接不显示
2. `todos.length > 0`
   —— 选了待办本但没数据，也不显示

比只看条数更准：没勾待办本时，同步可能拉到残留数据，
只看条数会误显示；第一级在"还没同步"时就能给出确定答案，不会闪一下。

## 待确认（需真机日志）
服务器是否真的返回 supported-calendar-component-set。
诊断日志已加：`日历本组件类型 <名称> → <类型>`。
若全是 unknown，说明服务器没声明 ⇒ 图标会退化成日历图标，
此时需要改用其它判据（如按本内是否含 VTODO 探测）。
 2026-11-02 22:32:51 +08:00
laoyang 98c4b6a96f feat: 待办可勾选完成 + 月视图事件圆点 #5 #6 
== #6 月视图事件标记（每日期最多一个圆点）==
应用市场反馈希望有事件的日期带标记。此前该功能存在但被移除，
原因是**按日历本逐个渲染**：3 个本 3 个点，15 个本满屏都是点。

- MonthCell 只加**一个布尔** hasEvent，不存每本一个的集合
- 用 buildEventDaySet() 一次遍历把有事件的日期收进 Set，
  渲染时 O(1) 查（避免 42 格 × N 事件的 O(n²)，本机近 3000 条数据会卡）
- 判定口径与 eventsOfDate 一致（区间相交）→ 跨天事件覆盖的每一天都有点
- 待办不计入（无时间点语义，混进来点会失去意义）
- 视觉用主题色 5vp 小点而非纯红：42 格里 30 个红点会吵，
  正是用户嫌乱的同类问题；选中日深底下换白色保证对比度
- 无事件时用等高透明占位，避免行高跳动

== #5 待办勾选完成 ==
先回答关键问题：**系统未开放待办 API**。
本机 SDK 检索 @ohos.calendarManager 全文，todo/VTODO/task 零命中，
Calendar/Event 只处理 VEVENT ⇒ 第三方应用无法读写系统「待办」页签。
故只能在本应用内实现，并已在待办页注明不会出现在系统待办中。

现状是**只读**（点击提示请在源端修改），本次补上写回：

- TodoService.setCompleted()：GET 原文 → 改状态字段 → PUT 回写
- EventDb: queryById / setTodoCompleted
- DavClient.getRawStrict()：失败**抛错**（原 getRaw 失败返回 HTTP 4xx
  字符串，若当 ICS 内容 PUT 回去会把待办覆盖成一句错误信息）
- IcsUtil.rewriteTodoCompletion()

⚠️ 两个关键设计：
1. **不重建 VTODO，只在原文上改字段**
   VTODO 有 SUMMARY/DESCRIPTION/DUE/PRIORITY/CATEGORIES/X-* 等字段，
   本地库只存了少数几个。重建后 PUT 会把没存的字段全部抹掉（丢数据）。
2. **两遍处理，与字段顺序无关**
   RFC 5545 不规定字段顺序。单遍实现若 STATUS 出现在 UID 之前，
   matched 仍为 false → 状态改不到 → 用户点完成没反应。
   改为第 1 遍定位目标 VTODO 块、第 2 遍在块内改写。
   插入补字段时按**块序号**定位而非行号（改动会删掉旧 COMPLETED 行，
   行号不再对齐，会让字段落到 END:VCALENDAR 之后，部分服务端直接 400）。

同步维护三个字段（按 RFC 5545，缺一个各客户端显示就不一致）：
STATUS / COMPLETED / PERCENT-COMPLETE。

UI：顶部新增「待办」标签（月/周/列表/待办），未完成在前、已完成在后，
点击勾选即写回；写回失败本地状态不变（避免界面与服务器不一致）。

验证：scripts/test-ics-todo.js 覆盖 26 项（状态在 UID 前/后、取消完成、
多 VTODO 只改目标、缺 STATUS 补字段、折行、结构完整性），全部通过。
编译 BUILD SUCCESSFUL。
 2026-11-02 14:48:43 +08:00
laoyang d0b8720c41 同步容错：服务器删除日历本后 404 不再导致整个账号同步失败 
- DavClient 新增 DavHttpError（带 HTTP 状态码），REPORT/PUT/DELETE 统一抛出
- 同步引擎对单本 404 跳过并自动从账号移除（先按 href 清行再迁移序号），
  全部日历本均 404 时保留账号配置并给出明确提示
- 推送阶段单条失败不再中断整个账号（401 凭据失效仍立即抛出）
- 编辑账号保存与自动移除都在序号迁移前先删被移除日历本的行，
  修复行混入其它日历本 calKey 的老问题（实测「读书」988 行混进「轻舟」）
- applyRemote 刷新行的 href：日历本被删除重建后集合 URL 变化，
  旧行不再残留死地址（编辑推送 404 / 永久卡待推送）
- pruneOrphanRows 追加 href 维度兜底清扫（跳过 dirty 行）
 2026-09-29 08:46:01 +08:00
laoyang 5ab9648b5a 修复了新增日历本颜色不对的问题。 
Signed-off-by: Yang Yongquan <i@yangyq.net>
 2026-09-15 23:03:58 +08:00
laoyang 5eaeeb0f4c 增强了安全配置。 
Signed-off-by: Yang Yongquan <i@yangyq.net>
 2026-09-15 12:51:58 +08:00
laoyang 0fef40c7f3 修复了部分日程没有提醒时间的问题。 2026-09-13 21:50:28 +08:00
laoyang 04fdf3d386 1.增加了重力感应，也就是横屏响应式布局。 
2.修改了沉浸式布局。
3.修改了添加日程和编辑日程页面，增加了重复、提醒等功能。
4.修改了权限问题，如果日历本是只读，则有删除线做标识。同时，对于只读的日程，点击后将不再进入编辑页面，而是展示详情。
5.系统日历的处理。给用户两个选择，第一个选择就是只显示系统日历。第二种选择，用户可以选择一个caldav账户中的某一个日历本，把系统日历中的日程，包括日历日程和应用创建的日程，都读取出来，然后加入到这个日历本下，最后同步到caldav的服务器上，这样的好处是，手机丢失了，或者换了手机品牌型号，手机上的日程仍然在自己的caldav服务器上有一个备份。当然，系统日历中的caldav日历，就不会再读取了。
 2026-09-13 20:25:18 +08:00
laoyang bbb3ec5334 首次提交：SyncCalendar 项目 2026-09-13 15:50:37 +08:00