Organisation and Teams Management

What problem will this feature address?

User Roles & Permissions

• Introduce owner and admin roles (currently, only member role exists).
• Add a custom user role with view-only access—users can only access assigned domains without creating project or deployment permissions. ( if required admin can allow start and stop container option)
• Enable permission updates for each role.
• Add the ability to transfer ownership.

Team Management

• Implement Teams to group members within an organization.
• Allow team-based invitations instead of inviting members individually (include an option to set a team size limit).
• Enable the option to register new users.
• Support adding descriptions for organizations and teams.
• Allow deleting expired or cancelled invitations.
• Provide an option to move members between teams.

Advanced Permissions & Access Control

• Enable assigning specific remote servers to selected users or teams.
• Introduce team-wide permissions to streamline access control for larger teams.

Describe the solution you'd like

A role-based access system with owner, admin, and a view-only user role, along with improved team management features like bulk invitations, team descriptions, and user movement between teams. Enhanced permission controls for assigning remote servers and granting team-wide access would streamline operations.

Describe alternatives you've considered

Currently, permissions and team management require manual configuration, which becomes inefficient as the organization scales. While we could continue with the existing setup, automating these processes with role-based access and team-wide permissions would significantly improve efficiency and security.

Additional context

No response

Will you send a PR to implement it?

Maybe, need help

Begin by reviewing the repository's existing organization, role, invitation, team, and remote-server permission entry points; no specific files or tests are named in the issue. Break the checklist into separately scoped changes and confirm the permission model before implementation. Done means the requested roles, team workflows, descriptions, invitation lifecycle, and user/team server access are implemented and tested.