Check All/Uncheck All do not make the table data "dirty" for Save purposes.

[GoogleCodeExporter]

I am not certain if this is user error because of how the grid is integrated 
with other functions on my website.

However, I have been able to edit individual rows without issue, so I may be 
misdiagnosing the cause, but the symptoms seem consistent.

1.  Using the "Check All" and "Uncheck All" functions from the right client 
context menu works well visually.  Check All and Uncheck All properly 
select/deselect the checkboxes.

However, when it comes time to save the data after a Check All selection, the 
Save button does nothing.

Based on inspecting the ajax calls, it appears that whatever flag is used to 
designate whether or not a row is "eligible" for saving is not set.  The save 
button does NOTHING until I physically select/deselect a single entry instead 
of using the check all/uncheck all option.

Inspecting the javascript code, it appears that after every action, you add the 
class "toBeSaved" to the parent row.  However, this does not occur in the 
checkAll/uncheckAll actions.

It's unclear to me whether or not there's an efficient way to process all the 
rows of data, but that might be something to consider.

Original issue reported on code.google.com by vep....@gmail.com on 31 Mar 2011 at 2:24

[GoogleCodeExporter]

You are correct that this is a bug. It only flags a row to be save when you 
focus on it, and checking and unchecking does not cause focus so it won't flag. 

Ill have that fixe in 1.6 coming very soon

Original comment by Seancla...@gmail.com on 31 Mar 2011 at 2:49

• Changed state: Accepted

[GoogleCodeExporter]

Do you have a sense of the strategy you would use for this?  For some reason 
iterating through all the tr's and adding that class seems inefficient, but I 
guess from a selector standpoint you're doing that anyway by setting everything 
to :checked.

Right now my short term fix would be to add that selector / change to the 
checkall/uncheck all events.

I guess in semi-related thinking, do you think ToBeSaved should only be applied 
if the data has actually changed?  The problem with testing it this way would 
be because of having to maintain a shadow version of the table to compare to 
--- which leads to the semi-obvious:  Does it make sense to have a Reset button 
to cancel your changes before you've hit the Save button?  (You could just 
reload the page, but maybe you don't want to?)

Original comment by vep....@gmail.com on 31 Mar 2011 at 3:28

[GoogleCodeExporter]

The solution was to
$(this).parents("tr").addClass("toBeSaved");

@side note
I think focus is ok, because it doesn't really hurt to send that field along 
and save it. Its 1 extra set in the UPDATE call, so its really more inefficient 
on the client to have to compare. 

Original comment by Seancla...@gmail.com on 10 Apr 2011 at 3:24

• Changed state: Fixed