[KULRICE-8126] Collection control does not honor disable if disable is disabled by an expression for collection refresh Created: 07/Sep/12  Updated: 21/Mar/13  Resolved: 05/Oct/12

Status: Closed
Project: Kuali Rice Development
Component/s: Development
Affects Version/s: 2.2.0-m4, 2.2
Fix Version/s: 2.2.1
Security Level: Public (Public: Anyone can view)

Type: Bug Fix Priority: Major
Reporter: Brian Smith (Inactive) Assignee: Brian Smith (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Similar issues:
KULRICE-12526Library - Progressive Disclosure Disable Collections add/delete not disabled with enable/disable selector
KULRICE-9846defaultValue not applied before disabled expression evaluation on initialization
KULRICE-13121Setting the disabled property on a ConcreteKeyValue in a KeyValuesFinder class does not disable that option in a drop down control
KULRICE-7211Default datePicker widget disabled property to disabled property on control
KULRICE-10392 Field triggers refresh on another field this is used in disable check, after refresh disable check does not run again
KULRICE-13117Disable Date Picker Control when the field is disabled
KULRICE-10771KRAD Demo Library Controls demonstrating Disable on keyup events initially disabled
KULRICE-7053spring expression error on refresh
KULRICE-12441Library - Controls - Disable on Key Event examples are ambiguous
KULRICE-11308LIbrary Client Responsiveness Disable Client-side Disable on keyup does not disable change button
Rice Module:
Application Requirement:
KAI Review Status: Not Required
KTI Review Status: Not Required


If SpringEL is setup to disable a control based on another control's value (this control is also part of the line), after a refresh of the collection the control will no longer be disabled even though when looking at java debugging, the control has its disabled property set to true by the expression evaluation. See client-side disable view for an example of this.

Comment by Brian Smith (Inactive) [ 05/Oct/12 ]

Tested, this was fixed somehow

Comment by Jessica Coltrin (Inactive) [ 08/Jan/13 ]

Since these were fixed on the trunk, they are 2.3.

Generated at Fri Dec 06 21:56:18 CST 2019 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.