Hi there, so I did an update from alpha2 to beta1 of this module and it looks like a real mess.. the biggest issue is that the "edit anyone's field.." seems to be enabled for all users for a bunch of fields - not all of them, and I couldn't find a correlation between the old site and the updated site, but there's seriously something wrong there.

Comments

also, "create own.. " and "edit own.." permissions for every field are set to all roles when running the update (those didn't exist at all before, as with edit anyone's..). This is highly critical and buggy, would really appreciate a fix.

Status:Active» Postponed (maintainer needs more info)

It's normal for permissions to be added during the update; the previous version of the module had a lot of "implied permissions" (for example, if edit/create permissions weren't enabled at all, then all users had permission to edit/create by default) whereas the current behavior of the module removes this concept and shows granted permissions explicitly. So it's by design that the update function will appear to add permissions in some cases. However, the actual functionality should not be changing.

If there's an actual functional bug here (meaning the actual behavior of what users were able to do changed) then please provide steps to reproduce and details of what happened - e.g., "Before the update authenticated users were able to do X and Y but not Z when editing a node, but after the update function ran they were able to do Z but not X and Y"... something along those lines.

Status:Postponed (maintainer needs more info)» Active

well, I didn't actually check if the users were able or not to do stuff shown in those permissions, but if the module on adding new permissions shows them all as "selected", even if they are actually not, that's just as bad a bug isn't it? E.g. "if edit/create permissions weren't enabled at all, then all users had permission to edit/create by default" - this can't possibly be true.. the default setting is that you can NOT edit anyone's nodes.

I guess it's OK to inherit the field permissions from the node permissions, but I had editing anyone's nodes disabled, and then when I did a field_permissions update, editing anyone's field was enabled in the permissions list.. so that's a bug imo.

Status:Active» Postponed (maintainer needs more info)

The permissions need to be enabled in that case because they reflect what Drupal normally allows you to do.

Naturally, some of those roles might not have permission to edit the node itself (so regardless of what field permissions they are granted, they will, as a practical matter, still not be able to edit the field), but as soon as you grant that role node edit permissions, by default Drupal would normally allow them to edit the fields also. So Field Permissions has to do the same thing, unless you've specifically said you don't want that role to be able to edit that particular field. That's why the checkboxes are checked.

Again, I don't think anything has changed here - just that the user interface is being more explicit about what the module was always doing. So at the moment I don't see any evidence of a bug.

well, I agree that if I had the "edit own/any [type] node" permission enabled, then having the "edit own/any [name] field" permissions enabled for all fields within that node makes sense (although it's questionable if two node types use the same field and you only have permission to edit one of those node types..).

But I did NOT have the edit permission enabled for ANY of the node types in my system. So when Field Permission created the "edit any/own field" permissions, it should really NOT have checked them by default when looking in admin/people/permissions. Yet it has.

Hope this convinces you that this is indeed not the correct behaviour.

Cheers