feat: new editor user permission profile

[chazzhou]

Description

This change introduces a new user permission profile called "editor" in the Dify workspace. The editor role can add and edit apps within the workspace, but does not have permission to manage certain workspace-level settings such as adding API keys, changing workspace models and tools, or enabling/disabling the API endpoint. However, editors can turn on/off and manage the published site for apps they have access to.

In addition, this change disallows normal users and editors to view logs, enhancing the security of the workspace.

The implementation also streamlines some places where permission checking was not using helper functions, and adds disabled states on the frontend for actions that editors do not have permission to perform.

Fixes # (issue)

Type of Change

• New feature (non-breaking change which adds functionality)
• Improvement, including but not limited to code refactoring, performance optimization, and UI/UX improvement

How Has This Been Tested?

• Verified editors can create and edit apps
• Confirmed editors cannot access workspace settings they don't have permission for
• Tested that editors can manage published app websites
• Checked disabled states appear correctly on frontend for editor role

Suggested Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I ran dev/reformat(backend) and cd web && npx lint-staged(frontend) to appease the lint gods
• optional I have made corresponding changes to the documentation
• optional I have added tests that prove my fix is effective or that my feature works
• optional New and existing unit tests pass locally with my changes

[VincePotato]

Could you provide more detailed information, such as why this new role is needed? Also, please list all the permissions related to the editor and explain them. @chazzhou

[chazzhou]

Hi @VincePotato, thanks for the question. I want to include the new "editor" role to provide more granular access control within Dify workspaces. It allows owners and admins to grant certain users the ability to create and manage apps, without giving them full control over workspace-level settings.

The main rationale is to enable sharing workspaces with users who need to design agents and workflows, but shouldn't be able to modify critical settings like the underlying language models, installed tools, API keys, etc. This is helpful for collaborating with less technical users who are trusted to build apps, but not necessarily to manage the entire workspace configuration.

Here's an overview of the permission hierarchy:

• Owner: Full control over the workspace and all settings
• Admin: Same app permissions as owner, plus ability to manage workspace settings
• Editor: Can create, edit, and manage apps, but cannot modify workspace settings
• Normal (Viewer): Can only use apps, cannot create or edit them

The key permission changes for the editor role are:

Endpoint	Method	Description	Previous Permission	New Permission
/apps/<uuid:app_id>/site-enable	POST	Enable/disable app website	None	Editor
/apps/<uuid:app_id>/api-enable	POST	Enable/disable app API	None	Admin
/apps/<uuid:app_id>/completion-conversations	GET	View completion conversations	None	Admin
/apps/<uuid:app_id>/completion-conversations/<uuid:conversation_id>	GET/DELETE	View/delete completion conversation	None	Admin
/apps/<uuid:app_id>/chat-conversations	GET	View chat conversations	None	Admin
/apps/<uuid:app_id>/chat-conversations/<uuid:conversation_id>	GET/DELETE	View/delete chat conversation	None	Admin
/workspaces/current/default-model	POST	Change default workspace models	None	Admin
/apps	POST	Create app	Admin	Editor
/apps/<uuid:app_id>	DELETE	Delete app	Admin	Editor
/apps/<uuid:app_id>/copy	POST	Copy app	Admin	Editor
/apps/import	POST	Import app	Admin	Editor
/datasets/<uuid:dataset_id>/documents	POST	Create dataset document	Admin	Editor
/datasets/init	POST	Initialize dataset	Admin	Editor
/datasets/<uuid:dataset_id>/documents/<uuid:document_id>/processing/<string:action>	PATCH	Process dataset document	Admin	Editor
/datasets/<uuid:dataset_id>/documents/<uuid:document_id>/metadata	PUT	Edit document metadata	Admin	Editor
/datasets/<uuid:dataset_id>/documents/<uuid:document_id>/status/<string:action>	PATCH	Change document status	Admin	Editor
/datasets/<uuid:dataset_id>/segments/<uuid:segment_id>/<string:action>	PATCH	Modify dataset segment	Admin	Editor
/datasets/<uuid:dataset_id>/documents/<uuid:document_id>/segments/<uuid:segment_id>	PATCH	Update document segment	Admin	Editor
/datasets	POST	Create dataset	Admin	Editor
/datasets/<uuid:dataset_id>	PATCH/DELETE	Modify/delete dataset	Admin	Editor
/tags	POST	Create tag	Admin	Editor
/tags/<uuid:tag_id>	PATCH/DELETE	Update/delete tag	Admin	Editor
/tag-bindings/create	POST	Create tag binding	Admin	Editor
/tag-bindings/remove	POST	Delete tag binding	Admin	Editor

In summary, the editor role provides a balance between enabling app creation/management and restricting access to workspace configuration. It's a useful addition for more flexible and secure collaboration within Dify.

Let me know if you have any other questions or suggestions! I'm happy to provide more details.

[crazywoola]

@takatost Have we tested this pr?

[chazzhou]

Hi everyone,

I've updated the PR to maintain compatibility with the recent front-end changes. The main change is that buttons for editing tools will now be disabled for editors and viewers.

Additionally, I've made an adjustment to the permissions for the following endpoint:

Endpoint	Method	Description	Previous Permission	New Permission
/apps/uuid:app_id/site	POST	Edit app site settings	Admin	Editor

This change grants editors the ability to modify app site settings, which was previously restricted to admin users only.

Please review the changes and let me know if you have any questions or concerns.

Thanks!

[nsvrana]

Just a note - this fixes a huge challenge we've had with Dify internally. Would love to see this released in a near future version. Ideally, in the future, Dify could go as far as to get to user/editor permissions on a per agent/bot/workflow basis.

[chazzhou]

@nsvrana I'm glad it helped!

Recent changes resolved the merge conflict with main.

[crazywoola]

Hello there can you resolve the conflicting files.

[crazywoola]

Cool :0

[crazywoola]

Hello, can you add my wechat crazyphage?

[dq7532183]

I am also doing this because a team can modify assistants created by others, so I want to create a role and can only view and edit the assistants I have created. The tags table already has the createduby field, which needs to be added to the apps

[ghost]

Must be admin or iwner

[liuzhenghua]

@takatost @crazywoola Can you help confirm with PM about my PR? #6950

In my opinion, creating new applications requires an architecture review, and deleting applications is a dangerous operation. These actions should not be performed by the editor role.

I'm also looking forward to Dify adding the ability for admins to configure specific apps that the editor role can definitely edit.

[nsvrana]

Please don’t change this role in the way you just described - for my use case either we need separate app by app permissions or editor needs to be able to create and delete.