Ajouter des rôles utilisateur et des autorisations réelles

Add user roles and permissions to this existing app. Login already works. The roles are [ROLE ONE], [ROLE TWO] and [ROLE THREE]. Use these descriptions: [ROLE ONE CAN SEE AND DO], [ROLE TWO CAN SEE AND DO], and [ROLE THREE CAN SEE AND DO].

Before changing anything, show me a plain-language matrix with the roles down one side and the important pages, information and actions across the top. Mark what each role can view, create, change and delete. Include logged-out visitors. Flag any unclear or conflicting instruction instead of guessing.

After I approve the matrix, enforce it on both the screens and the stored information. Hiding a menu item is not protection. If someone types a private page address directly or changes an item number in the address, the app must still refuse access to anything outside that person's permission.

Use the safest default when a rule is missing: deny the action and show a calm message. A [CUSTOMER ROLE] may see and change only [THEIR OWN INFORMATION]. A [STAFF ROLE] may see and change [ASSIGNED OR SHARED INFORMATION]. A [OWNER ROLE] may manage [OWNER-ONLY AREAS]. Adjust these examples to match my approved matrix.

Add an owner-only user management screen where [AUTHORIZED ROLE] can view a person's current role and change it. Users must never choose a more powerful role for themselves through sign-up, profile editing or a changed page address. Keep a small history showing who changed a role, whose role changed, the old role, the new role and the time.

Do not confuse live app roles with builder access. Staff who use the finished app should not automatically gain access to the builder, project settings, private connection keys or deployment controls.

Test with one account for every role and one logged-out window. Try the normal navigation, direct page addresses, viewing another person's record, changing allowed information and attempting one forbidden action. Do not use real customer accounts or data.

Keep the existing design and make denied-access messages clear rather than frightening. Finish with the approved matrix, the test results and anything that remains broader than I requested.