[KULRICE-10439] AttributeSecurity hide attribute is not handled correctly Created: 10/Sep/13 Updated: 21/Apr/14 Resolved: 16/Sep/13
|Project:||Kuali Rice Development|
|Component/s:||Development, KNS Equivalency, Roadmap|
|Security Level:||Public (Public: Anyone can view)|
|Reporter:||Kristina Taylor (Inactive)||Assignee:||Kristina Taylor (Inactive)|
|Remaining Estimate:||0 minutes|
|Time Spent:||1 day, 6 hours|
|Original Estimate:||3 days|
|Epic Link:||Inquiry Equivalence|
|KRAD Feature Area:||
|Sprint:||2.4.0-m2 Sprint 2, 2.4.0-m2 KRAD Sprint 3|
|KAI Review Status:||Not Required|
|KTI Review Status:||Not Required|
|Code Review Status:||Not Required|
|Include in Release Notes?:||
In the KNS, you could hide an entire field in the Inquiry based on KIM permissions by adding AttributeSecurity to the DD
This would have the effect of removing the entire row (description and value) from the interface if a permission based on the KR-NS / View Inquiry or Maintenance Document Field template was not assigned to the current user. In KRAD, there are several issues that prevent this from working.
I believe the additional check for AttributeSecurity should just be added to ViewAuthorizerBase.canViewField. Then, the p:render="false" and p:hidden="true" attributes will be set correctly. I will update the KNS2KRAD guide separately to reflect what this should be.
|Comment by Kristina Taylor (Inactive) [ 12/Sep/13 ]|
There are some inconsistencies in the KNS that make this one a bit more difficult to solve. Even though this issue is for Inquiry, the places that we need to change will affect Inquiry, Lookup, and Maintenance. If we set attribute security to hide, this is how the KNS acts:
This is how KRAD acts with my fixes:
The represent either features I am unaware of or bugs. The way I got these changes was to add the following four lines to copyFromAttributeDefinition in both DataField and LookupInputField:
The one other thing I will probably have to do is convert all of the Authz fields from boolean to Boolean and prevent them from initializing at first so the overrides are done correctly. Not quite sure what effects this will have, as the ComponentSecurity objects are all automatically initialized, so perhaps we should have a lazy init and default to false?