🚀 Feature: Console Roles

[patrice-blp]

🔖 Feature description

Create role-based resource access control. User data should not be updated by default by any administrator. Updating the data should be the responsibility of the users and the password should be updated by sending a link in the user's mail (from the console).
In the case of wanting a system where administrators can update user data, it should be specified by a configuration variable "_APP_DISABLE_PLATFORM_USERS_ROLES" or by configuration within the admin console.

🎤 Pitch

Any administrator can update user data and can reset the user's password without the user knowing.

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[stnguyen90]

@patrice-blp, thanks for raising this issue! 🙏 This is the expected and intended behavior. Admins should have full access to the project to update users.

[patrice-blp]

@stnguyen90 thank you very much for your answer.
If it is intentional, it would be better that each project chooses if it wants the administrator to be able to update the data (name, email, password, phone) of the users by configuration (environment variable).

If we invite a user to be an administrator we should be able to customize access.

Another option would be to have access to resources based on roles "RBAC" (Admin, Sales, Marketing, etc...).

[stnguyen90]

@patrice-blp would you please update this issue to be a feature request for additional Appwrite Console roles?

[patrice-blp]

@stnguyen90 I have updated the issue to be a feature. Thanks.

[stnguyen90]

Some scenarios we'll need to support:

• Instance level restrictions
  • Restrict creating orgs
• Org level restrictions
  • Limit access to projects (instead of access to all projects)
  • Limit access to create projects
  • Restrict who can invite users to an org
  • View vs update on billing details (which would also limit emails about billing)
  • Prevent deleting of an org
• Project level restrictions
  • Read only access
  • Granular create/read/update/delete access in each service

Ideally, it would be nice to have something like scopes and allow developers/admins to create roles with whatever scopes so they can fully customize the access they need to grant.

Are there any other scenarios or use cases anyone can think of?