[KULRICE-13211] Investigate attachmentTypeCode and KIM Permissions. Created: 09/Sep/14  Updated: 11/Nov/14  Resolved: 09/Oct/14

Status: Closed
Project: Kuali Rice Development
Component/s: Analysis
Affects Version/s: 2.5.1
Fix Version/s: 2.5.1
Security Level: Public (Public: Anyone can view)

Type: Task Priority: Major
Reporter: Steve Edgar (Inactive) Assignee: Jonathan Keller
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: HTML File Attachment_Permission_Test.html     PNG File TravelDocument_Attachment_Permissions.png    
Rice Team: Middleware
Sprint: Middleware 2.5.1 Sprint 2
KAI Review Status: Not Required
KTI Review Status: Not Required
Code Review Status: Not Required
Include in Release Notes?:
Story Points: 5


This is related to KULRICE-13090, where it was desired to create a set of KIM permissions which would allow the following scenario…

A KIM principal receives a Travel Account Maintenance document in its “Action List”, and is able to see the Notes and Attachments section of that document, but is not be able to see the “Download Attachment” button.

Currently, DocumentAuthorizerBase.canViewNoteAttachment() is called, once to authorize for the visibility of the Notes and Attachments section, and once to authorize for the visibility of the “Download Attachment” button. Authorization for the “Download Attachment” button can be based on “attachment type code”, as canViewNoteAttachment() takes that as an optional parameter.

I attempted to get the needed KIM permissions in place, but was unsuccessful. I consulted with Kristina, who provided some additional investigation, and it was decided to write up a Jira case to further investigate the situation.

The goals of this case are …

  • Determine the KIM permissions and roles for the above scenario.
  • If KIM modifications are required, implement those, if they are minor. Any major KIM changes should first be reviewed by a KIM expert.
  • Add an AFT to DemoTravelAccountMaintenanceViewPermissionAft.java to test the scenario.

Comment by Jonathan Keller [ 07/Oct/14 ]

I'll take this one. We use attachment type-based permissions extensively in the UCD KFS implementation.

Comment by Jonathan Keller [ 09/Oct/14 ]

So - initial investigation shows that the issue is that the permissions are not overriding each other on this type.

There is both a permission for all attachments and one for the OTH attachment type. (See screen shot) Theoretically, that should block out the other permission, but it is not. Both are being considered in that case, making it additive.

This may be a preexisting issue, but is certainly not how we want it to behave.

I'm going to look into how hard it would be to make permissions of this type with an attachment type override those without.

Comment by Jonathan Keller [ 09/Oct/14 ]

Attaching Selenium IDE script used to test fix

Comment by Jonathan Keller [ 09/Oct/14 ]

Fix verfied (with attached Selenium script) and checked in.

Still need to create an AFT to validate.

Comment by Martin Taylor (Inactive) [ 11/Nov/14 ]

Closing 2.5.1 Development

Generated at Fri Aug 14 21:08:39 CDT 2020 using JIRA 7.0.11#70121-sha1:19d24976997c1d95f06f3e327e087be0b71f28d4.