Super Productivity 任务归档完全指南如何归档、恢复与排错【免费下载链接】super-productivitySuper Productivity is an advanced todo list app with integrated Timeboxing and time tracking capabilities. It also comes with integrations for Jira, GitLab, GitHub and Open Project.项目地址: https://gitcode.com/GitHub_Trending/su/super-productivitySuper Productivity 是一款把时间盒Timeboxing给任务分配固定时间段和时间追踪集成在一起的进阶待办应用。用上个一两周已完成那一栏很容易堆起几十个任务把它们一条条删掉又可惜。应用里的归档功能就是把这些完成任务从活跃列表搬进一个独立的长期仓库列表保持干净数据一条不少。下面从使用角度把这套机制讲透——怎么归档、数据落在哪里、如何恢复以及遇到报错时怎么排查。为什么 Super Productivity 要把完成任务搬出列表想象一下如果你永远不归档活跃列表会无限长大。每个任务都要参与界面渲染、搜索和多设备同步列表越慢同步包越大。归档的本质是一次搬家完成任务连同它的时间追踪记录从活跃列表移除写入归档存储归档里的任务不再出现在项目列表、今日视图或日程里但 ID 没变报表和历史查询照样能查到它同步时不传归档内容本身只传把这些任务归档这样的操作指令每台设备本地执行同一套确定性逻辑最终得到一模一样的归档布局。官方对这套设计有一份非常清楚的说明建议作为延伸阅读任务归档机制。30秒看懂归档两层货架一条规则归档不是一个大文件而是分成两层层级装什么同步节奏近期归档recent大约最近 21 天内归档的任务及其时间数据每次日常同步都会带上旧归档old超过 21 天的更早任务只在冲刷flush时批量搬入为什么是 21 天这是一个平衡点长到足够覆盖你回看最近几周、做周报复盘的需要短到近期层不会无限膨胀。到了阈值应用自动把近期层里的旧数据冲刷进旧层近期层保持有界同步包也因此保持轻量。有一条铁律值得记住子任务永远跟着父任务一起归档层级结构不会散架。归档任务的三个常用入口不管从哪个入口触发最终都会汇到同一个函数task.service.ts 里的moveToArchive。它负责过滤、去重、先落盘再更新界面状态。你日常会用到的是这三个入口工作视图的归档已完成任务按钮。任务做完打勾后它们会留在已完成区。点击按钮后work-view.component.ts 中的moveDoneToArchive会把当前所有完成任务一次性归档并用一条已归档 N 个任务的提示告诉你结果。结束一天的流程。在每日总结里完成收尾时应用会把当天完成的任务归档让第二天的列表从零开始。查看与恢复归档任务。仓库里有专门的归档任务查看对话框dialog-view-archived-task/回看历史任务时从这里进。moveToArchive内部其实做了两件很关键的防护一是用一张进行中的记录表防止同一个任务被重复归档重复的操作会被安全跳过同步重试也不会产生脏状态二是先调用 archive.service.ts 把任务持久化到归档存储之后才派发 NgRx 的归档动作。顺序不能反——如果先更新了内存状态而归档还没落盘快照里就可能出现任务已被移出列表但归档里查不到的裂缝。如何把归档任务恢复回活跃列表归档区是只读的你不会直接在归档里编辑一条任务唯一回到活跃列表的方式是恢复restore。恢复后任务带着原来的 ID 重新出现在列表里之后随便改。这条设计有个好处任何归档操作都可以放心重试因为一个任务要么在活跃列表要么在归档里状态永远明确不会出现两条半归档的副本。时间追踪数据也随任务一起搬家归档时进入近期层冲刷时整体转入旧层。所以做报表时应用会把活跃列表、近期归档、旧归档三处的时间数据合并成一份一致视图历史时长不会丢。归档对任务属性有哪些增删可以看 任务属性说明数据具体存在数据库哪个位置见 用户数据文档。排错为什么偶尔弹出Trying to move sub tasks into archive for project⚠️ 这条报错值得单独说因为它是归档相关里最常出现的异常对应 issue #4846。场景是你在项目上下文里归档但传入的任务数组是扁平的——父任务和它的子任务同时作为独立条目存在。此时moveToArchive会筛出所有带parentId的条目发现数量不为 0又在非标签上下文里于是直接抛错。它的设计意图是好的防止子任务脱离父任务被单独归档成孤儿。问题出在上游把子任务也塞进了数组。正确的数据形态是数组里只有顶级任务子任务挂在父任务的subTasks里。修法也就一行const tasksToArchive doneTasks.filter((t) !t.parentId);这个问题状态 → 期望状态 → 一行修复的完整推演被固化在了测试文件 move-to-archive.spec.ts 里做技术评审或排查时直接读它比读散落的代码更快。另外注意一个容易混淆的细节在标签上下文比如今日视图它本质是一个标签下行为完全不同——系统不会把子任务归档而是直接从子任务上移除该标签让任务自然消失。看到归档行为在不同视图下表现不一样多半就是这个上下文判断在起作用。同步为什么归档多了同步包却不会变大 归档系统对同步的友好程度是它最容易被低估的地方。它从不把整个归档当作一个文件传每台设备收到的是操作日志里的指令例如归档任务 A、B把近期层冲刷到旧层每台设备本地执行同一套确定性逻辑各自写入本地归档任务 ID 按确定顺序存储保证各设备重放后归档布局一致如果某次冲刷失败可以回滚到上一状态归档不会处于半新半旧的中间态。换句话说归档再大同步传输的也只是一小串移动指令。想了解操作日志的完整架构读 operation-log-architecture.md多设备冲突如何收敛延伸阅读 数据同步机制。上手清单四步把任务列表收拾利索每天收尾完成的任务打勾后点工作视图上的归档按钮一键清场第二天的列表从空白开始。别手动管冲刷近期→旧层的 21 天迁移是自动的你只需要确认归档视图里近期层的数据能正常查到。回看历史用归档任务对话框查看需要改就先恢复、再编辑不要在归档里直接动。遇到子任务报错对照 move-to-archive.spec.ts 检查传入数组是否混入了子任务条目归档前只保留顶级任务即可。【免费下载链接】super-productivitySuper Productivity is an advanced todo list app with integrated Timeboxing and time tracking capabilities. It also comes with integrations for Jira, GitLab, GitHub and Open Project.项目地址: https://gitcode.com/GitHub_Trending/su/super-productivity创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Super Productivity 任务归档完全指南：如何归档、恢复与排错
Super Productivity 任务归档完全指南如何归档、恢复与排错【免费下载链接】super-productivitySuper Productivity is an advanced todo list app with integrated Timeboxing and time tracking capabilities. It also comes with integrations for Jira, GitLab, GitHub and Open Project.项目地址: https://gitcode.com/GitHub_Trending/su/super-productivitySuper Productivity 是一款把时间盒Timeboxing给任务分配固定时间段和时间追踪集成在一起的进阶待办应用。用上个一两周已完成那一栏很容易堆起几十个任务把它们一条条删掉又可惜。应用里的归档功能就是把这些完成任务从活跃列表搬进一个独立的长期仓库列表保持干净数据一条不少。下面从使用角度把这套机制讲透——怎么归档、数据落在哪里、如何恢复以及遇到报错时怎么排查。为什么 Super Productivity 要把完成任务搬出列表想象一下如果你永远不归档活跃列表会无限长大。每个任务都要参与界面渲染、搜索和多设备同步列表越慢同步包越大。归档的本质是一次搬家完成任务连同它的时间追踪记录从活跃列表移除写入归档存储归档里的任务不再出现在项目列表、今日视图或日程里但 ID 没变报表和历史查询照样能查到它同步时不传归档内容本身只传把这些任务归档这样的操作指令每台设备本地执行同一套确定性逻辑最终得到一模一样的归档布局。官方对这套设计有一份非常清楚的说明建议作为延伸阅读任务归档机制。30秒看懂归档两层货架一条规则归档不是一个大文件而是分成两层层级装什么同步节奏近期归档recent大约最近 21 天内归档的任务及其时间数据每次日常同步都会带上旧归档old超过 21 天的更早任务只在冲刷flush时批量搬入为什么是 21 天这是一个平衡点长到足够覆盖你回看最近几周、做周报复盘的需要短到近期层不会无限膨胀。到了阈值应用自动把近期层里的旧数据冲刷进旧层近期层保持有界同步包也因此保持轻量。有一条铁律值得记住子任务永远跟着父任务一起归档层级结构不会散架。归档任务的三个常用入口不管从哪个入口触发最终都会汇到同一个函数task.service.ts 里的moveToArchive。它负责过滤、去重、先落盘再更新界面状态。你日常会用到的是这三个入口工作视图的归档已完成任务按钮。任务做完打勾后它们会留在已完成区。点击按钮后work-view.component.ts 中的moveDoneToArchive会把当前所有完成任务一次性归档并用一条已归档 N 个任务的提示告诉你结果。结束一天的流程。在每日总结里完成收尾时应用会把当天完成的任务归档让第二天的列表从零开始。查看与恢复归档任务。仓库里有专门的归档任务查看对话框dialog-view-archived-task/回看历史任务时从这里进。moveToArchive内部其实做了两件很关键的防护一是用一张进行中的记录表防止同一个任务被重复归档重复的操作会被安全跳过同步重试也不会产生脏状态二是先调用 archive.service.ts 把任务持久化到归档存储之后才派发 NgRx 的归档动作。顺序不能反——如果先更新了内存状态而归档还没落盘快照里就可能出现任务已被移出列表但归档里查不到的裂缝。如何把归档任务恢复回活跃列表归档区是只读的你不会直接在归档里编辑一条任务唯一回到活跃列表的方式是恢复restore。恢复后任务带着原来的 ID 重新出现在列表里之后随便改。这条设计有个好处任何归档操作都可以放心重试因为一个任务要么在活跃列表要么在归档里状态永远明确不会出现两条半归档的副本。时间追踪数据也随任务一起搬家归档时进入近期层冲刷时整体转入旧层。所以做报表时应用会把活跃列表、近期归档、旧归档三处的时间数据合并成一份一致视图历史时长不会丢。归档对任务属性有哪些增删可以看 任务属性说明数据具体存在数据库哪个位置见 用户数据文档。排错为什么偶尔弹出Trying to move sub tasks into archive for project⚠️ 这条报错值得单独说因为它是归档相关里最常出现的异常对应 issue #4846。场景是你在项目上下文里归档但传入的任务数组是扁平的——父任务和它的子任务同时作为独立条目存在。此时moveToArchive会筛出所有带parentId的条目发现数量不为 0又在非标签上下文里于是直接抛错。它的设计意图是好的防止子任务脱离父任务被单独归档成孤儿。问题出在上游把子任务也塞进了数组。正确的数据形态是数组里只有顶级任务子任务挂在父任务的subTasks里。修法也就一行const tasksToArchive doneTasks.filter((t) !t.parentId);这个问题状态 → 期望状态 → 一行修复的完整推演被固化在了测试文件 move-to-archive.spec.ts 里做技术评审或排查时直接读它比读散落的代码更快。另外注意一个容易混淆的细节在标签上下文比如今日视图它本质是一个标签下行为完全不同——系统不会把子任务归档而是直接从子任务上移除该标签让任务自然消失。看到归档行为在不同视图下表现不一样多半就是这个上下文判断在起作用。同步为什么归档多了同步包却不会变大 归档系统对同步的友好程度是它最容易被低估的地方。它从不把整个归档当作一个文件传每台设备收到的是操作日志里的指令例如归档任务 A、B把近期层冲刷到旧层每台设备本地执行同一套确定性逻辑各自写入本地归档任务 ID 按确定顺序存储保证各设备重放后归档布局一致如果某次冲刷失败可以回滚到上一状态归档不会处于半新半旧的中间态。换句话说归档再大同步传输的也只是一小串移动指令。想了解操作日志的完整架构读 operation-log-architecture.md多设备冲突如何收敛延伸阅读 数据同步机制。上手清单四步把任务列表收拾利索每天收尾完成的任务打勾后点工作视图上的归档按钮一键清场第二天的列表从空白开始。别手动管冲刷近期→旧层的 21 天迁移是自动的你只需要确认归档视图里近期层的数据能正常查到。回看历史用归档任务对话框查看需要改就先恢复、再编辑不要在归档里直接动。遇到子任务报错对照 move-to-archive.spec.ts 检查传入数组是否混入了子任务条目归档前只保留顶级任务即可。【免费下载链接】super-productivitySuper Productivity is an advanced todo list app with integrated Timeboxing and time tracking capabilities. It also comes with integrations for Jira, GitLab, GitHub and Open Project.项目地址: https://gitcode.com/GitHub_Trending/su/super-productivity创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
