This is in fact the 'expected' behavior whenever the role has been given the "Add notes" permission (which corresponds with@:add_issue_notes@ [source:/trunk/lib/redmine.rb@13892#L107]) as your screenshots show. I'll elaborate.
When the issues context menu is being rendered, the (bulk-)edit elements are marked disabled based on the condition !@can[:edit]
(source:/trunk/app/views/context_menus/issues.html.erb@13892#L4). This condition is met if the user misses the :edit_issues
permission for any project inside the @projects
array (source:/trunk/app/controllers/context_menus_controller.rb@13892#L32, where @projects
is defined in the #find_issues
before filter).
Whenever we talk about the "Edit" button on the single issue view (source:/trunk/app/views/issues/show.html.erb@13892) the situation is different. This specific button is rendered as part of a separate partial, only whenever @issue.editable?
returns true (source:/trunk/app/views/issues/_action_menu.html.erb@13892#L2), which is the case when the user either has the :edit_issues
or the :add_issue_notes
permission for the current issue's project (source:/trunk/app/models/issue.rb@13892#L154).
Now, to come back to your scenario, you have a user who is granted the :add_issue_notes
permission, but not the :edit_issues
permission. As outlined above the user sees the regular "Edit" button on the single issue view. Clicking this button will lead them to a form where only the "Notes" fieldset is available (because they need to be able to add notes to issues) and where rendering of the "Change properties" fieldset is omitted, as such preventing them from editing issue properties. This "Change properties" fieldset is rendered only if the user has the :edit_issues
permission.
So, in the end this seems to be just an UI issue regarding the "Edit" element of the issues context menu which does not consider the same permission set as the "Edit" button on the issues show view does.