However, it was noted that there were at least four different ways the Issue actions might report this to the user.

1. Custom handling in the operation view. Creates a very nice error page with the operation, and friendly error message - http://server/jira/secure/AddComment!default.jspa?id=12345
2. "You are not logged in" message with standard Jira banner, user gets redirected to permission-violation page (permissionviolation.jsp), not so friendly, but the user gets the point - http://server/jira/secure/ViewIssue.jspa?id=12345 (note, this page has trackback info)
3. "Access Denied" message with big red background, user gets redirected to security-breach page (securitybreach.jsp) with standard Jira banner, not so friendly big red message, user still gets the point - http://server/jira/secure/attachment/12345/logs_jira-int_11_03_2005.txt or the ViewVoters or ManageWatchers urls (no trackback info).
4. 500 page catches IssuePermissionException, very, very unfriendly message, lots of nasty logging.

These need to be standardised so all access denied reports are the same, and it is not possible to view any secure information if you do not have that permission.

While researching JRA-10205 the following was noted:

• IssuePermissionException is handled inconsistently. We need to either throw it from our Action.doValidate(), Action.doExecute() & Action.doDefault() methods or handle it in a consistent manner.
• We probably should handle the standard case in the framework. AbstractIssueSelectAction holds the issueObject, and should be able to handle 99% of the code paths. Attached is a version that does the 99% (doesn't handle the trackback case)
• We could further generify the issue handling of Actions by having them implement some kind of IssueAware interface and have an interceptor of the filter stack read the request parameters and insert the Issue into the action. This could also have a PermissionException injector method as well if the user cannot see an issue. (Please ask Scott for further information, as this is his idea).
• The trackback info is the wrinkle edge-case, we do actually have to provide some issue info in the trackback rdf if enabled.

Final caveat: The permission error page actually DOES HAVE TO HAVE the issue summary in it (if incoming trackbacks are turned on) in the trackback RDF. This currently works if the permissionviolation.jsp is the result (which it is for ViewIssue). We probably need to have a separate TrackbackIssueInfo object that the Issue can give us that is filtered through a trackback policy filter. Then we can have a trackback policy for enabling/disabling trackbacks based on their security (for instance allow trackbacks for public issues only, rinse issue summary from non public issues etc.)