Fix for Bug # 372. Bulk editing a field without first going through the

element profile and without adding or removing or reordering field elements
now preserves the data. This is another bug that has been in the code since
the beginning of time, and was only recently identifyed. Thanks to Rachel
Murray for the spot!

lib/Bric/Biz/Asset/Business/Parts/Tile/Container.pm

@@ -8,16 +8,16 @@ tiles
 
 =head1 VERSION
 
-$Revision: 1.18 $
+$Revision: 1.18.4.1 $
 
 =cut
 
-our $VERSION = (qw$Revision: 1.18 $ )[-1];
+our $VERSION = (qw$Revision: 1.18.4.1 $ )[-1];
 
 
 =head1 DATE
 
-$Date: 2003-01-29 06:46:03 $
+$Date: 2003-04-12 21:02:28 $
 
 =head1 SYNOPSIS
 
@@ -1586,7 +1586,12 @@ sub _sync_tiles {
     my ($self) = @_;
     my ($tiles,$del_tiles) = $self->_get('_tiles', '_del_tiles');
 
-    return unless $self->_get('_update_tiles');
+    # HACK. I don't think that this was really necessary, because each tile
+    # wil only be saved and trigger a change to the database if it was
+    # actually changed in some way. This is similar to how collections work.
+    # So I'm commenting this out and just saving all the tiles every time.
+    # -DW 2003-04-12.
+#    return unless $self->_get('_update_tiles');
 
     foreach (@$tiles) {
 #               if ($prep_clone) {

lib/Bric/Changes.pod

@@ -95,6 +95,14 @@ Stories with subelements containting no field elements no longer cause an
 error when the container profile is looking for contextual information to
 display about a a subelement. Thanks to Chris Jantzen for the spot. [David]
 
+=item *
+
+Bulk editing a field without first going through the element profile and
+without adding or removing or reordering field elements now preserves the
+data. This is another bug that has been in the code since the beginning of
+time, and was only recently identifyed. Thanks to Rachel Murray for the spot!
+[David]
+
 =back
 
 =head1 VERSION 1.5.2