Member Role Can Delete Projects Not Assigned to Them & Suggestion for Granular Permission Controls

[haysquareA]

I encountered a critical permission issue on my Coolify instance where a user with a member role was able to delete a project that was not assigned to them. According to the role-based access guidelines, members should only manage projects they’re explicitly assigned to. This behavior poses a security risk and could lead to unintended data loss.

Additionally, I would like to suggest an enhancement to the permission system: a more granular, configurable permissions model. This would allow instance owners to decide precisely what level of authority each role (or even individual users) should have—for example, granting full authority, read-only access, or restricted operational rights to certain projects or environment variables.

Steps to Reproduce:

Set up a Coolify instance with multiple users (Owner/Admin and one or more Members).
Create several projects and ensure that some projects are not assigned to the member in question.
Log in as a member who is not assigned to a specific project.
Navigate to the project management section and attempt to delete a project that the member is not assigned to.
Observe that the deletion operation is permitted and executed successfully.
Expected Behavior:

Members should only be able to view and manage projects to which they are explicitly assigned.
Actions on projects outside their assigned scope should be blocked, with an appropriate permission error message.
The system should offer configuration options to define granular permissions, enabling instance owners to assign full authority or restrict certain operations as needed.
Actual Behavior:

The member was able to delete a project they were not assigned to, indicating that the permission checks are not functioning as intended.
Environment Details:

Coolify Version: v4.0.0-beta.397
Deployment Method: self-hosted on hosting

I have verified that this behavior is reproducible with multiple member accounts.
Audit logs confirm that the deletion was carried out by an unauthorized member.
The current permission model appears to allow members access to sensitive operations (such as viewing environment variables and deleting projects/servers) even when they are not assigned to them.
Feature Suggestion: Implement a configurable, granular permission-based system that enables owners to tailor the level of access and authority for each role. This would help prevent unintended actions and offer more precise control over what each user can do.
Steps Taken:

Reviewed the Coolify documentation regarding member permissions.
Verified that user roles are configured correctly in the instance.
Attempted to replicate the behavior with different member accounts, with consistent results.
Request:
I request that the development team investigate this permission escalation issue to ensure that members can only manage projects they are assigned to. Additionally, I propose considering a more granular permission control system that would allow for detailed customization of user rights. This enhancement could help address similar issues in the future and improve overall security.