docs: release note v1.9.0

website/blog/2023-09-15-v1.9.0.md

@@ -0,0 +1,39 @@
+---
+title: Release Note v1.9.0
+authors: moonrailgun
+image: /img/logo.svg
+slug: release-1.9.0
+keywords:
+  - tailchat
+tags: [Release Note]
+---
+
+### Feature updates
+
+#### Add panel-level permission control management
+
+![](/img/blog/release-note/v1.9.0/1.png)
+
+A panel field has been added to the permission registration. When this field is set and matched to a certain panel type, the permission will be displayed in the advanced permission control.
+
+Permission design is based on whitelist form. This means that he will inherit the group's permissions.
+
+Example one:
+- This role in the group **has** the [Send Message] permission
+- This role **does not** have the [Send Message] permission in the panel
+- Finally, this character has the [Send Message] permission in all text panels
+
+Example two:
+- This role in the group **does not** have the [Send Message] permission
+- This role **has** the [Send Message] permission in the panel
+- In the end, this role only has the [Send Message] permission in the panels with permissions set above, and does not have the permission to send messages in other panels.
+
+> Q: Why does tailchat use the union of panel permissions and group permissions instead of permission override?
+>
+> A: Because compared to many fixed-design applications, Tailchat needs to consider the design of the plug-in. The plug-in can register customized permissions, and these permissions are uncontrolled. Only by allowing users to develop the habit of whitelisting permission management during their operations and actual use will the permissions not be out of control when new plug-ins are added. In addition, the behavior of overwriting is more unpredictable because it will overwrite each other.
+>
+> An example is, if we want users to have no permissions in a certain panel, but have permissions in other panels, then the most convenient way is to set the group scope to have permissions, but the panels have no permissions. The lack of permissions on the panel will override the permission design of the group. But there is a difference here. We don’t know whether the user expects to have permissions by default or not by default. But currently he has permissions except for a certain panel. The difference between the two is that when a new panel is added, whether he expects to have permissions or not. permission denied. Tailchat wants to eliminate the mental coverage and understanding costs that the difference between the two situations brings to users, so it chose the most conservative way to design the permission system.
+
+### Other updates
+
+- Fixed a possible xss attack because we allowed iframes to pass in srcdom, which could inject inline style code.

website/i18n/zh-Hans/docusaurus-plugin-content-blog/2023-09-15-v1.9.0.md

@@ -0,0 +1,39 @@
+---
+title: 版本发布日志 v1.9.10
+authors: moonrailgun
+image: /img/logo.svg
+slug: release-1.9.10
+keywords:
+  - tailchat
+tags: [Release Note]
+---
+
+### 特性更新
+
+#### 增加面板级别的权限控制管理
+
+![](/img/blog/release-note/v1.9.0/1.png)
+
+在权限注册中增加了panel字段，当这个字段被设定并匹配到某一面板类型时，权限将会在高级权限控制中显示
+
+权限设计基于白名单形式。这意味着他会继承群组的权限。
+
+示例一:
+- 群组中该角色**拥有**【发送消息】权限
+- 在面板中该角色**没有**【发送消息】权限
+- 最终该角色拥有在所有文本面板的【发送消息】权限
+
+示例二:
+- 群组中该角色**没有**【发送消息】权限
+- 在面板中该角色**拥有**【发送消息】权限
+- 最终该角色仅在上述设定拥有权限的面板拥有【发送消息】权限，其他面板没有发送消息权限
+
+> Q: 为什么tailchat会采用面板权限与群组权限取并集的形式而不是权限覆盖的形式？
+>
+> A: 因为相比于很多固定设计的应用来说，Tailchat需要考虑到插件的设计，插件可以注册自定义的权限，而这些权限是不受控的。只有在用户的操作中与实际使用中让用户养成白名单的权限管理习惯，才会让当新的插件加入时不会出现权限失控的情况。另外覆盖的行为是更加不可捉摸的行为，因为他会相互覆盖。
+> 
+> 一个例子是，如果我们想要让用户在某个面板没有权限，但是其他的面板有权限，那么最方便的做法是设定群组范围有权限，而面板没有权限。面板的没有权限会覆盖群组的权限设计。但是这里有一个分歧在于我们并不知道用户期望的是默认有权限还是默认没有权限但是目前除某个面板以外都有权限，这两者的差异在于当新的面板被添加时期望是有权限还是没有权限。tailchat想要消除这两种情况的差异对用户带来的心智覆盖和理解成本，因此选择了最保守的方式设计权限系统。
+
+### 其他更新
+
+- 修复了一处可能的xss攻击，因为我们允许iframe传入srcdom，而这是可以注入行内样式代码的。