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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

arski’s picture

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.

David_Rothstein’s picture

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.

arski’s picture

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.

David_Rothstein’s picture

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.

arski’s picture

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

mariacha1’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Active

Probably should look at this before doing another release, especially if we release a non-beta version of the module, in case anyone is still on alpha1 and decides to update.

mariacha1’s picture

Going through old tickets, I don't seem to be able to reproduce this. Upgrading from alpha2 to beta1 with the following permissions:

Basic Page:
Only Admins have "Edit" permission for the node:

Only admins can edit this node

And no one can edit the Body field on the node:

Edit own and edit any unchecked

After upgrading, the new labels of "Edit anyone's/own value for field body" are still unchecked

Edit anyone's and own body values are the same.

If the argument is that field permissions should not be enabled if the node-level permissions are not enabled, that's not something we are likely to do.