了解 POLICR MINI 的开发分支以及新的更新
前言
很久，没有发布过 Policr Mini 的更新内容了。在此之前，先祝大家五一节日快乐。本文会对新增的 develop 分支进行基本介绍，还包括升级方法，更新内容，更新预告等。
需要提前说明的是，直到本文的发布这些更新也没有上线到官方实例中。大量的更新如果一次上线，因为长久未大规模测试，是非常危险的。所以短期内本文的更新并不会上线到官方实例中，自行部署的用户可以更新到开发分支帮助测试，以让更新能早日上线官方实例。
分支介绍
自 2021 年 12 月底起，policr-mini 项目的开发几乎停滞了，这是因为新的代码不再向 master 分支合并（或直接提交）了。考虑到零零碎碎的更新和频繁的升级并不是非常有必要的，还会致使机器人可靠性降低，所以新的代码长期以来都在另一个重要的次分支 develop 上继续提交。
升级教程
升级过程很简单，您需要编辑一下配置文件，并执行更新和重新部署命令。
参考：https://github.com/Hentioe/policr-mini/blob/develop/UPGRADE.md
更新内容
编译器/运行环境/依赖升级
- Elixir 版本从 1.12 升级到最新的 1.13.4
- Erlang 版本从 24.1 升级到最新的 24.3.3
- 基础镜像从 debian:buster 升级到 debian:bullseye
- 包括 React 和 TailwindCSS 在内的核心前端依赖全部升级到最新版
以上升级意味着基础更加牢固，阻碍开发进度的历史包袱也被大量丢下。
新的消息清理器
消息清理器是设计用于删除消息的内部功能，它被完全重构，可靠性大幅提高。为什么需要所谓的「消息清理器」而不是简单直接的删除消息？
因为消息可能临时性删除失败，例如网络原因或短时间内产生了大量的并发删除请求。以及，消息可能有延迟删除的需要。这表示消息清理必须是一个包含自动重试、延迟执行、限制并发等基础设计的功能。
新的消息清理器在此基础上还支持任务持久化到磁盘，即使机器人重启后也能恢复待执行的删除任务，尽可能保证出现意外情况也不在群内滞留应该删除的消息。
注意：当前 develop 分支并未启用消息清理任务的持久化。
新的解封方法和自动解封
在此前的实现中，踢出动作是分为两个步骤完成的，也就是封禁再延时解封。此处的封禁和解封两个动作是明确执行的，在 recent actions 中也可以看到机器人分别执行了这两个操作。这并不是完美的方案，因为机器人在封禁用户后可能出现意外情况，会导致相关用户未能及时解封甚至“被忽略”解封。我们总要考到它会发生 ，即使可能性很低。
新的解封方法是 TG 帮机器人自动解封用户，它也能达到延时解封的效果，且不会有以上担忧。当前解封方法需要明确配置。
使用新的解封方法：
POLICR_MINI_UNBAN_METHOD=until_date
继续用旧的解封方法：
POLICR_MINI_UNBAN_METHOD=api_call
新的解封方法基于 banChatMember 的 until_date 参数，基于这个参数实现自动解封无需再执行解封动作。这会导致 recent actions 不会有解封操作的记录，但这并不表示用户仍被封禁。在 Removed Users 列表中可以看到相关用户已不存在。
退出检查
在最初的实现中，当群组被销毁或移除机器人后，系统并不会自动移除与之相关的权限记录。这导致后台中显示的群列表会出现这类不应该存在的群。
明明它已经不在了但是还会显示，看着很恼火。
首先要明确即使这类群组存在，会显示出来，且能继续修改设置，但不存在任何安全风险。值得庆幸的是，这类群组将在未来消失。本质上这属于「数据错误」，是历史遗留的下来的，无法避免但可被纠正。为此，机器人在系统中添加了一个任务，专门检查这些已退出和已销毁的群，现在这些群一旦被系统发现就会自动屏蔽所有人的权限记录，不会再显示于任何人的后台群列表中了。
目前退出检查任务的执行周期是每日执行一次。
新的超时处理任务
超时处理是在用户验证超时后执行的任务，它是一个典型的延时执行任务的内部功能，已被完全重构。
新的超时处理支持从失败中恢复，持久化到磁盘（重启后恢复），可自由停止，执行时间更加精确。这些优势带来了更小的系统开销，更可靠的执行结果。
手动终止验证的支持
在此前的实现中，当管理员从后台「验证记录」页面对正在等待验证的用户实施「封禁」或「踢出」操作时，机器人不会对已经创建的验证进行干预。这导致用户明明已经被手动处理了，但验证还在继续执行，这是不应该的。
得益于刚才介绍过的对超时处理的重新设计，现在这个部分已经被完善了。如果管理员通过后台验证记录封禁或踢出用户，而该用户的验证状态是“等待”时，相关验证任务会被同步。如果操作的是「封禁」按钮，验证会直接结束，超时处理被取消，验证结果变成「手动封禁」。操作「踢出」按钮时也会有类似效果。
在未来增加针对个人的独立验证消息支持后，消息内联按钮的相同操作也会因为此次实现而获益得到十分可靠的效果。
被废弃的动态权限
从一开始的基础功能实现，就已经存在基于动态的权限限制和解除限制的设计。这里的动态仅针对等待验证和验证成功的用户。简单来说，在不同的群机器人可能会对用户操作不同的权限。这是因为机器人读取了群全局（或者说默认）权限，并基于全局权限设置来对该群的新成员进行权限操作。
但是，经过仔细考察和思考后，我们认为这是一种不必要的设计。
实际上管理员无法给用户恢复全局权限中被关闭的权限。即使在解封时固定的开放所有权限，它通常也无法达到实际效果，因为 TG 会直接忽略对超出群全局权限中的限制解除。假设某群的全局权限中关闭了发表投票权限，那么即使机器人恢复了这个权限，该用户也没有获得这个权限。
所以跟随群全局权限，并基于此解除限制，这种“完美”的构想，是多余的。解除限制时直接开放所有权限这样简单粗暴的方式反而能达到理想效果，因此动态权限恢复已经被完全弃用。如果从 recent actions 中看到机器人恢复了全部权限也不要紧张，这是安全的。
系统任务页面
后台的系统菜单中，新增了一个系统任务页面。此页面当前会显示所有的定时任务信息。在未来此页面会支持手动触发定时任务，显示任务结果，甚至创建任务。
当前这些定时任务通常是用于修正系统中存在的错误状态或数据的一系列特殊任务，它们由系统自身创建和调度。
BUG 修复
- 自定义问题添加答案时，将忽略空白答案。避免 #100 中描述的现象。
- 重复点击只读权限群组的部分菜单链接，会让背景中的只读水印消失。
已知问题
- 从全局属性页面上传图片验证资源包时，可能会失败。具体原因尚未查明，但是已经被多次反馈过。因一直无法复现而搁置，它可能和 Nginx 或部署方法，甚至浏览器有关。
期待您的反馈。
更新预告
不知道你们是否有注意到，实际上 TG 官方支持“加入请求”已经有一段时间了。此功能可以让管理员审核用户加入，在管理员批准之前，请求加入的用户仅仅只是发了一个请求而已。这项功能可以避免用户不经过同意进群（即使机器人验证，也是已进群状态），但是它仅支持私有链接。
Policr Mini 项目对自己的定义很明确，只做验证，并不断的优化，改善，将仅此单一功能做到极致。很显然，私有链接的加入请求以及管理员审核（批准或拒绝），是能继续发挥的基础。
当前本项目有一个基于此的新功能构想：
机器人使用自己的链接托管群组的对外链接，当用户访问链接时页面上会提示验证。通过验证以后，会生成一个指向机器人命令的链接，当用户通过此链接导航发出机器人命令时，机器人会回复原始私有链接。
当用户点击私有链接后机器人将直接批准他的加入请求，因为此时用户已经通过了验证。只不过验证的凭证被包含在命令中了，并且凭证的有效期非常短且只对发送此凭证的人有效。
这种验证方式暂定作「网页验证」，它适合没有入群门槛（无需回答专业问题），仅屏蔽机器人帐号（程序化控制的用户）加入的群组。
此构想很快会进行实施，不出意外会和文本介绍的开发分支更新一并上线官方实例。
结束语
开发分支的更新还需要继续测试，希望更多人将自己的实例升级到开发分支帮忙测试。具体上线到官方实例的时间待定。
但如上有提，网页验证实现后一定会尽可能快的把所有更新上线到到官方实例。
谢谢大家。