Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 14:13:35 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #797] [FEAT]: New user role that can view, create, modify and delete (their own) workspaces #465

New Issue
Closed
opened 2026-02-22 18:19:37 -05:00 by yindo · 4 comments
yindo commented 2026-02-22 18:19:37 -05:00
Owner
Copy Link
Copy Source

Originally created by @v3DJG6GL on GitHub (Feb 26, 2024).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/797

What would you like to see?

There are currently three user roles: Default, Manger and Admin.
What I think is missing is something between Default and Manger:
I would like to give some of my users roles where they can create, delete and modify their own workspaces - e.g. change the LLM model, LLM temperature and so on.
Currently I have to assign the Manger role to my users to do this. But this role includes many more admin permissions that they should not have - such as Can create, update and invite new users to the instance.

Originally created by @v3DJG6GL on GitHub (Feb 26, 2024). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/797 ### What would you like to see? There are currently three user roles: _Default_, _Manger_ and _Admin_. What I think is missing is something between _Default_ and _Manger_: I would like to give some of my users roles where they can create, delete and modify their own workspaces - e.g. change the LLM model, LLM temperature and so on. Currently I have to assign the _Manger_ role to my users to do this. But this role includes many more admin permissions that they should not have - such as _Can create, update and invite new users to the instance_.
yindo added the enhancementfeature request labels 2026-02-22 18:19:37 -05:00
yindo closed this issue 2026-02-22 18:19:37 -05:00
yindo commented 2026-02-22 18:19:38 -05:00
Author
Owner
Copy Link
Copy Source

@sumitsodhi88 commented on GitHub (Feb 26, 2024):

and they should have access to their docs only

@sumitsodhi88 commented on GitHub (Feb 26, 2024): and they should have access to their docs only
yindo commented 2026-02-22 18:19:38 -05:00
Author
Owner
Copy Link
Copy Source

@olariuromeo commented on GitHub (Feb 27, 2024):

I think this is not enough, I think there must be a component that can create roles and permissions. So each admin can create an infinity of roles that he can manage as he wishes. and can assign to each role the permissions it wants. I think we all agree that each admin has different requirements for his platform.
Therefore, each field must have the possibility to be configured with different rights mixed on different roles.
Therefore, the platform must have different levels of granularity and rights that can be configured on each level up to the atomic level of the field.
Thus, fields can be grouped into groups of fields, which can also have rights that can be assigned to roles. at this level.
Then above there could be plugins or modules that can be integrated into the platform that can also have roles with assigned rights. This pirmaidal system of roles can be assigned different rights on different levels, thus an infinity of roles with different rights can be created, which could give the possibility for the platform to be used as everyone wants. Atomic level modularity is essential, but we cannot talk about such things when there is not even a registration form on the platform. There is no user or role management system. all these are created manually, they cannot be created dynamically at the moment. So I estimate that if this is desired, it will probably be possible in a few years. But I think that the best approach for this application is to have a system of defining roles and users through api, so the application can be integrated into any cms or application as a module, and users can have access from there, where they already there is a community and a user management system. But to be possible, each function on the platform must be able to have clear definitions at the granular level of the field, to be able to be configured through api. Otherwise, this application will remain just one of the millions of applications on github, which is not used by anyone except the developer and a few dreamy enthusiasts. This application does not allow the creation of users and roles through api or directly from the platform, users must be created by each admin. this is nonsense, and the roles cannot be created even by the admin. so the application is useless. Whoever spends money on such an architecture lives only in the hope that this will happen in the future. I do not recommend building a business based on this application. It is just one of thousands of attempts to do something, but the application is totally lacking in vision. It is not enough to be a good programmer to make an application, you need an architect with a vision, so that the application becomes a success and gains popularity. I tested the application and it has a lot of errors. it does not have a user and role management system, so it seems useless to me. it is only good for the one who created it. So each admin is a user who pays monthly or annually. Nothing more!

@olariuromeo commented on GitHub (Feb 27, 2024): I think this is not enough, I think there must be a component that can create roles and permissions. So each admin can create an infinity of roles that he can manage as he wishes. and can assign to each role the permissions it wants. I think we all agree that each admin has different requirements for his platform. Therefore, each field must have the possibility to be configured with different rights mixed on different roles. Therefore, the platform must have different levels of granularity and rights that can be configured on each level up to the atomic level of the field. Thus, fields can be grouped into groups of fields, which can also have rights that can be assigned to roles. at this level. Then above there could be plugins or modules that can be integrated into the platform that can also have roles with assigned rights. This pirmaidal system of roles can be assigned different rights on different levels, thus an infinity of roles with different rights can be created, which could give the possibility for the platform to be used as everyone wants. Atomic level modularity is essential, but we cannot talk about such things when there is not even a registration form on the platform. There is no user or role management system. all these are created manually, they cannot be created dynamically at the moment. So I estimate that if this is desired, it will probably be possible in a few years. But I think that the best approach for this application is to have a system of defining roles and users through api, so the application can be integrated into any cms or application as a module, and users can have access from there, where they already there is a community and a user management system. But to be possible, each function on the platform must be able to have clear definitions at the granular level of the field, to be able to be configured through api. Otherwise, this application will remain just one of the millions of applications on github, which is not used by anyone except the developer and a few dreamy enthusiasts. This application does not allow the creation of users and roles through api or directly from the platform, users must be created by each admin. this is nonsense, and the roles cannot be created even by the admin. so the application is useless. Whoever spends money on such an architecture lives only in the hope that this will happen in the future. I do not recommend building a business based on this application. It is just one of thousands of attempts to do something, but the application is totally lacking in vision. It is not enough to be a good programmer to make an application, you need an architect with a vision, so that the application becomes a success and gains popularity. I tested the application and it has a lot of errors. it does not have a user and role management system, so it seems useless to me. it is only good for the one who created it. So each admin is a user who pays monthly or annually. Nothing more!
yindo commented 2026-02-22 18:19:38 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Feb 27, 2024):

@olariuromeo There is no Github issue for this, but atomic permissions are actually WIP. There are just many models and access points that must be presented in a comprehensible way for the average administrator. You do not have the appropriate background to frame why the system is the way it is currently, but this tool is an iteration moving towards a future state that actually does align with your desires, oddly enough. These larger architectural changes are for the core team only since they involve the entire framework of the application.

Every detail of your comment would be better expressed as a Github issue to voice your view on any specific feature or decision and what you would like to see. Why you would write the above comment and possibly think that would be helpful to the maintainers or community is very off-putting and communicates your ideas poorly.

This project is open source and constantly evolving as the landscape changes, if you have problems or a better "vision" - you are allowed to build it if you think it is more important or we are not moving fast enough.

Best of luck. In the meantime, we will continue to build AnythingLLM from the voice of our community ✌️

@timothycarambat commented on GitHub (Feb 27, 2024): @olariuromeo There is no Github issue for this, but atomic permissions are actually WIP. There are just many models and access points that must be presented in a comprehensible way for the average administrator. You do not have the appropriate background to frame why the system is the way it is currently, but this tool is an iteration moving towards a future state that actually _does_ align with your desires, oddly enough. These larger architectural changes are for the core team only since they involve the entire framework of the application. Every detail of your comment would be better expressed as a Github issue to voice your view on any specific feature or decision and what you would like to see. Why you would write the above comment and possibly think that would be helpful to the maintainers or community is very off-putting and communicates your ideas poorly. This project is open source and constantly evolving as the landscape changes, if you have problems or a better "vision" - you are allowed to build it if you think it is more important or we are not moving fast enough. Best of luck. In the meantime, we will continue to build AnythingLLM from the voice of our community ✌️
yindo commented 2026-02-22 18:19:38 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Jun 28, 2024):

Moving to https://github.com/Mintplex-Labs/anything-llm/issues/1787

@timothycarambat commented on GitHub (Jun 28, 2024): Moving to https://github.com/Mintplex-Labs/anything-llm/issues/1787
yindo changed title from [FEAT]: New user role that can view, create, modify and delete (their own) workspaces to [GH-ISSUE #797] [FEAT]: New user role that can view, create, modify and delete (their own) workspaces 2026-06-05 14:35:27 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label enhancement feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#465
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?