Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I was under the impression this module would hide fields in a view as well if the user doesn't have permission to see them.
It doesn't seem to happen on my site. The node itself hides the fields as per design, but when checking a views generated page, all fields are shown.
Did find a similar issue, on external site: http://drupal.stackexchange.com/questions/2095/views-module-bypasses-fie...
Any help or clarification is welcome, thanks!
Comment | File | Size | Author |
---|---|---|---|
#6 | field-permissions-views-1141330-6.patch | 3.9 KB | David_Rothstein |
#5 | field-permissions-views-1141330-5.patch | 2.51 KB | David_Rothstein |
Comments
Comment #1
RobLoach#1124298: Views does not check hook_field_access()?.... I believe in here, we should probably eventually return FALSE:
... Until at least Views might eventually check field_access for individual elements.
Comment #2
bryancasler CreditAttribution: bryancasler commentedsubscribe
Comment #3
geerlingguy CreditAttribution: geerlingguy commentedSubscribe.
Comment #4
BeaPower CreditAttribution: BeaPower commentedsub
Comment #5
David_Rothstein CreditAttribution: David_Rothstein commentedI posted a patch at #1124298-20: Views does not check hook_field_access()? which, when applied to the Views module, should fix the Field Permissions integration.
With that patch applied, there isn't much we actually need to do with the Views-integration code in this module. Mostly just adjust the code comments and remove some code that is no longer needed.
We may want to eventually make the change Rob Loach suggests in #1, but that would only be the case if #1273534: Pass entity when calling field_access happens in Views eventually. (It would be nice to do that, since the code referred to in that comment is a little weird, but as mentioned above it doesn't seem to be necessary to fix the main problem.)
The patch here is rolled on top of #1279712: Revamp the Field Permissions user interface to make it more intuitive (i.e., only applies after that one has been committed) since the expectation is that will go in relatively soon and it didn't seem worth the effort to have to reroll the patch again.
Comment #6
David_Rothstein CreditAttribution: David_Rothstein commentedWe can actually modify this slightly to improve the experience in the case of private fields.
When a private field is specifically included in a View, it makes sense to allow privileged site administrators to access it as part of the View (even though we normally deny view access when it is shown as part of an entity since we don't want sensitive content randomly and unexpectedly showing up in random places around the site, even for admins).
This idea was discussed at one point in #1279712: Revamp the Field Permissions user interface to make it more intuitive and is now implemented in the attached.
Comment #7
RobLoachGoing to leave this for a while for some internal testing before alpha2 comes out.... http://drupalcode.org/project/field_permissions.git/commit/83da13a
Comment #9
odizle CreditAttribution: odizle commentedHi, I am using the 7.x-1.0-beta2 and having the same problem. dose this patch is also for this version ?
Comment #10
zilla CreditAttribution: zilla commentedany idea if this issue has been resolved? it also came up in the views hacks module issues queue, but seems to me to be something that should be a core component of field permissions because FP is exposed to views - but maybe that's just my opinion - perhaps it could be exposed as a conditional (contextual relationship of some kind? anybody doing it this way?)
Comment #11
demonde CreditAttribution: demonde commentedIn my case the field is hidden.
But it should not be hidden, when the view has 'role access' permission and not 'view content' permission, since this should overwrite any other permission.
Should a seperate issue be opened for this?
Comment #12
zopa CreditAttribution: zopa commentedretracting my comment
Comment #13
milos.kroulik CreditAttribution: milos.kroulik commentedPatch from #6 no longer applies and the code looks completely different now.
EDIT: The module works correctly even without the patch.
Comment #14
rooby CreditAttribution: rooby commented@milos.kroulik:
That is because this issue has been marked as fixed, which means that patch has been committed to the module.