Role permissions in Redmine define what a project member can see and change after a role is assigned. They matter when one team needs issue access without project administration rights, or when client-facing users need a narrower project surface than the default Manager or Developer roles.
The role editor separates project, issue tracking, wiki, repository, time-tracking, and visibility settings. Issue permissions also use tracker coverage, so allowing issue creation requires both the permission checkbox and tracker coverage for the trackers used by the project.
Test a new role with an account that has no other role in the target project. Redmine combines permissions when a member has multiple roles, so a single-role test account shows whether the new permission set grants the intended actions and blocks project administration actions.

Use Copy workflow from when the new role should follow the issue workflow of an existing role such as Developer.
A support role can view issues, add issues, and add notes, while edit, delete, and project administration permissions remain unchecked.

The test user should have only this role in the project, otherwise another role can mask an over-restricted or over-permissive setting.
Related: How to add members to a Redmine project
The form confirms that View Issues and Add issues work for the project tracker.
https://redmine.example.net/projects/field-service/settings/members
If project settings open for the test user, remove high-risk permissions such as Edit project, Select project modules, or Manage members from the role and retest.