---
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.
