Closed (duplicate)
Project:
Field Permissions
Version:
7.x-1.0-beta1
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
22 Oct 2011 at 20:45 UTC
Updated:
23 Jul 2016 at 20:54 UTC
Jump to comment: Most recent
Comments
Comment #1
robloachTry going back to alpha1, uninstalling, and then re-installing beta1. There is an upgrade path, but the upgrade path is handled by upgrade.php....
Comment #2
robloach..... or uninstalling from beta1. hmmm.
Comment #3
robby.griffin commentedWould uninstalling remove all my old field permissions though? I'm trying things out in a test server, but I don't know this module well enough to predict how uninstalling affects things.
Comment #4
robby.griffin commentedUninstall, update module, then enable does the trick. However, it wipes all previously created field permissions, so takes snapshots and remake them after updating. Would love to see the upgrade path work, but at least I can use it again.
Comment #5
zeip commentedAs far as I could tell, it removed the data altogether when doing the update – am I correct? If so, it would be crucial to add a note about this on the release notes.
Comment #6
robby.griffin commentedThat is correct. All the data in any node that had field permissions (including fields that weren't protected) was completely wiped. I had to restore from a backup and recreate any parts that weren't on the backup. Adding this issue to the release notes would be very helpful I imagine.
Comment #7
Taxoman commentedComment #8
David_Rothstein commentedUninstalling a module always removes its settings. That's how Drupal works :)
In terms of the original bug report, I think this needs exact steps to reproduce. (I.e., something like this: "Install Drupal 7 with Field Permissions version X, configure your site by doing X, Y and Z, then update to 7.x-1.0-beta1, and your site will break.") I've tested this module's upgrade path a number of times and never saw any problem at all, so if there is a problem it must be only under certain specific conditions.
It's also really hard to believe that there is any actual data loss caused by the Field Permissions module, since the Field Permissions update does not touch any of the site's data at all.
Comment #9
zeip commentedI can't currently tell the exact steps to reproduce this on a fresh install. However, I reproduced this again when doing updates on a site – On the production site table field_data_[fieldname] has five rows, on the test install after upgrading field_permissions from 1.0-alpha1 to beta1 the table is empty. I'd really hope you'd put up a warning about this on the release notes, it's a very nasty bug to come by!
I can try to get some more info after I've done the updates.
Comment #10
goldlilys commentedMy problem is not that it's breaking the site, but when using the custom permissions, I don't see the different types of options per field. It seems to just refresh the page and nothing happens.
Comment #11
zeip commentedI traced this bug to some point. It's not about Field permissions, as David suspected. The bug occurs when using the function field_update_field(), which uses field_has_data() to determine if the field has data, but incorrectly sees many of my site's fields as empty. Because of this, field_update_field() removes all the data and completely regenerates the field when a parameter is changed at field_permissions.install.
Comment #12
zeip commentedThere seems to be an issue about this: #1302228: field_has_data() returns inconsistent results – possible data loss.
Comment #13
mariacha1 commentedNot sure how relevant this is since beta1 is 5 years old, so closing as a duplicate of https://www.drupal.org/node/1302228