[KULRICE-12301] View flag for disabling growls should disable client side growls as well Created: 27/Mar/14  Updated: 16/Jan/15

Status: Open
Project: Kuali Rice Development
Component/s: Development, User Experience (UX)
Affects Version/s: None
Fix Version/s: 2.6
Security Level: Public (Public: Anyone can view)

Type: Task Priority: Major
Reporter: Jerry Neal (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: Old
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Issue Links:
relies on KULRICE-8365 Validation change/fix interaction aft... Closed
Similar issues:
KULRICE-11615Example code for server-side and client-side growls is the same
KULRICE-8627Document client side disable functionality
KULRICE-10049Client-Side disable not working with Coll. SpringEL Functions
KULRICE-8126Collection control does not honor disable if disable is disabled by an expression for collection refresh
KULRICE-11308LIbrary Client Responsiveness Disable Client-side Disable on keyup does not disable change button
KULRICE-7217Implement growls processing
KULRICE-10395Allow for disabled expressions to be partially evaluated server side
KULRICE-10054SpringEL for disable client-side is broken
KULRICE-7007Add flags to view to disable storing of form in session
KULRICE-9032cancelling a document with client side validation disabled
Epic Link: Technical Issues
Rice Team: Framework
KAI Review Status: Not Required
KTI Review Status: Not Required
Code Review Status: Not Required
Include in Release Notes?:


The view component has property growlMessagingEnabled. This was originally added when adding the Growl type to MessageMap. The intention was if growls were added to the mesage map, to allow them to be displayed as info messages instead.

However, growls are also shown client side in places (like the validation framework), and there is no way to prevent them without overriding code. It makes sense for this view property to disable all growls for a view regardless of where they come from. Therefore we need to modify the client side code to check this view setting.

Note the related Jira on validation handling. It might be decided that growls should not be used at all for validations, therefore this would become irrelevant.

Finally, the javadocs isGrowlMessagingEnabled and setGrowlMessagingEnabled have some content and formatting issues that need cleaned up.

Comment by Jerry Neal (Inactive) [ 28/Apr/14 ]

Another possibility. We now only use growls to display JS error notifications. However, we are considering how those notifications are given.

Generated at Thu Jun 04 07:01:52 CDT 2020 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.