Is it possible to control display of specific fields by permissions or role within a view result ?

@merlinofchaos

Thanks for prompt reply.

> If the field is a CCK field, then you can use the field permissions module to restrict fields from users.

The CCK field within type Definition referencing DefinedTerm is called field_defined_term_ref. This is accessed indirectly in the view, which uses a viewfield field_vf_backlinks_definitions to access the many Definitions of a DefinedTerm, and they are formatted by a view backlinks_defined_by_definitions.

Even when I disable field permission view field_defined_term_ref for a given role, the title link generated for a Definition is visible to that role, even when that link is correctly not displayed on the node of a Definition (which has a direct reference link to a DefinedTerm).

If you want it only for this view, you can, on the same view, set up multiple page displays with the same path with different access settings. Put the *most* restrictive one first, and the least restrictive one last (i.e, lower in the list of displays). The most restrictive one has the most detail.

My bold. Thanks, that might do it, I'll report back.

@merlinofchaos who wrote:

... , set up multiple page displays with the same path with different access settings. ...

This worked like a charm. I set up 2 differently named Page displays for my view backlinks_defined_by_definitions:

- Page_author ('author' role access), which shows linked title for privileged 'author' role users.

- Page_authenticated ('authenticated' role access), which only shows the Definition node's body and other metadata (but no link to the Definition node).

Both Page displays have identical paths as instructed: definitions/backlinks)/%

When I call directly on the view page by path passing nid as arg, I did get the title nicely filtered out for "mere" authenticated users, just as desired. It is a very powerful feature, thanks for describing it.

However, I have now a secondary issue involving ViewField (nothing to do with Views, however I'll report on a solution here as well, it might help others). My ViewField field_vf_backlinks_definitions in my custom type DefinedTerm (representing a technical term that is defined by one or more Definition nodes), has to be pointed at one of the view Page displays. See attached image showing pulldown offering a choice for this view between:

backlinks_defined_by_definitions - Defaults
backlinks_defined_by_definitions - Page_author
backlinks_defined_by_definitions - Page_authenticated

No matter which one I choose, it does not seem to pickup the Views role switching trick:

- When I choose display Page_author, "mere" authenticated users can't see the embedded viewfield at all, presumably because it is calling on Page_author and failing access.

- When I choose display Page_authenticated, privileged 'author' role users can't see the extra linked title, presumably because it is calling on Page_authenticated, which of course by design does not show the extra linked title.

I will try some other backlinks modules and report back.

The following only applies to my attempt to embed the display of fields filtered by role for a backlinks case, the solution given by merlinofchaos for simple direct page loads works fine.

I tried using back references from Node Relationships, it did not seem to be able to distinguish between the different Page displays, and it seem to take the default.

I cloned and adapted my multi-Page access restrictive view from above to the correct form for Node Relationships (at least I hope so, cloning and adapting something other than the noderelationships_backref view template is a little error prone). The display served fine, however it did not filter the displayed fields per role.)

The Node Relationships backref user interface pulldown for the view to use does not offer different displays within a view, it seems to be taking the default, and is not catching the Views page-access-by-role trick you described.

Again, only concerning embedding views with fields filtered by role as backlinks

To be sure, I cloned the noderelationships_backref template and reconstructed the different Page displays per access from scratch, to ensure compatibility with Node Relationships. However it does not let me edit the paths, I am getting slightly different paths for the different role-specific Page displays:

In the Views UI the greyed out input field showing the path for each Page is greyed, out, and for Page_author it looks like this:

noderelationships/noderelationships_defined_by_d2/page
'The path assigned to this view is dynamically customized by the Node Relationships module.'

However for Page_authenticated it looks like:

noderelationships/noderelationships_defined_by_d2/page-1

Note the extra '-1', I can't edit it to make it the same as the path for the other Page_author.

Q1: Why can't I change the paths in the View UI ? Why are they greyed out ?

Not sure whether this has to do with Views or Node Relationships:

Q2: Do you know how I can override the view cloned from noderelationships_backref so that the Page paths are editable, so I can ensure the are identical (so that the Page access trick works).

Grateful for suggestions.

Reactivated as support request (although original feature request met for basic cases wonderfully, however not met when combined with backlinks modules, not Views fault, however maybe you have the answer).

In the view cloned from noderelationships_backref (and adapted to introduce role-specific Page displays) I examined the View settings and found:

View tag:

The tag assigned to this view is marked readonly because it is used to trigger the dynamic customizations of the view performed by the Node Relationships module.

Do you merlinofchaos (or markus_petrux of Node Relationships) know whether there is some special behind-the-scenes feature that is likewise making the path readonly (which is thwarting implementation of the nice Views trick you described for choosing between role-specific Page displays with identical path).

xref to Node Relationships:

#767910: Integration of (cloned and adapted) noderelationships_backref view with per-role Page displays (sharing identical path) in View

Having same trouble exploiting the per-role Page access trick with View Reference that I had with Viewfield. I seem to have to choose between one role-specific Page display or another, I can't "have me cake and eat it" relying on identical paths.

@merlinofchaos

Could you please examine this view export to see whether any setting there would prevent me from editing the paths ? If not, then it seems Node Relationships is intercepting something somewhere. I've snipped some irrelevant field stuff:

$view = new view;
$view->name = 'noderelationships_defined_by_d2';
$view->description = 'Cloned from noderelationships_backref template, then made access-aware by Page';
$view->tag = 'noderelationships_backref';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('relationships', array(
  'field_source_document_ref_nid' => array(
    'label' => 'Source (Document)',
    'required' => 0,
    'delta' => '-1',
    'id' => 'field_source_document_ref_nid',
    'table' => 'node_data_field_source_document_ref',
    'field' => 'field_source_document_ref_nid',
    'override' => array(
      'button' => 'Override',
    ),
    'relationship' => 'none',
  ),
));
$handler->override_option('fields', array(
..
  ),
));
$handler->override_option('filters', array(
..
));
$handler->override_option('access', array(
  'type' => 'none',
  'role' => array(),
  'perm' => '',
));
$handler->override_option('cache', array(
  'type' => 'none',
));
$handler->override_option('use_ajax', TRUE);
$handler->override_option('items_per_page', 0);
$handler->override_option('use_pager', '0');
$handler->override_option('use_more', 1);
$handler->override_option('style_options', array(
  'grouping' => '',
));
$handler = $view->new_display('page', 'Page_author', 'page');
$handler->override_option('access', array(
  'type' => 'role',
  'role' => array(
    '3' => 3,
  ),
));
$handler->override_option('empty', 'No items were found.');
$handler->override_option('items_per_page', 25);
$handler->override_option('use_pager', '1');
$handler->override_option('path', 'noderelationships/noderelationships-backref');
$handler->override_option('menu', array(
  'type' => 'none',
  'title' => '',
  'description' => '',
  'weight' => 0,
  'name' => 'navigation',
));
$handler->override_option('tab_options', array(
  'type' => 'none',
  'title' => '',
  'description' => '',
  'weight' => 0,
));
$handler = $view->new_display('page', 'Page_authenticated', 'page_1');
$handler->override_option('fields', array(
  'body' => array(
    'label' => '',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'strip_tags' => 0,
      'html' => 0,
    ),
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'exclude' => 0,
    'id' => 'body',
    'table' => 'node_revisions',
    'field' => 'body',
    'override' => array(
      'button' => 'Override',
    ),
    'relationship' => 'none',
  ),
  'title_1' => array(
    'label' => 'Source',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'strip_tags' => 0,
      'html' => 0,
    ),
    'empty' => '',
    'hide_empty' => 1,
    'empty_zero' => 0,
    'link_to_node' => 1,
    'exclude' => 0,
    'id' => 'title_1',
    'table' => 'node',
    'field' => 'title',
    'override' => array(
      'button' => 'Override',
    ),
    'relationship' => 'field_source_document_ref_nid',
  ),
));
$handler->override_option('access', array(
  'type' => 'role',
  'role' => array(
    '2' => 2,
  ),
));
$handler->override_option('path', 'noderelationships/noderelationships-defined-by-d2/page-1');
$handler->override_option('menu', array(
  'type' => 'none',
  'title' => '',
  'description' => '',
  'weight' => 0,
  'name' => 'navigation',
));
$handler->override_option('tab_options', array(
  'type' => 'none',
  'title' => '',
  'description' => '',
  'weight' => 0,
));

If you can't see anything suspicious I'll seek support as a Node Relationships issue: #767910: Integration of (cloned and adapted) noderelationships_backref view with per-role Page displays (sharing identical path) in View.

Please keep this open, I want report back here on which combination of Views + "a backlinks module" can be used successfully in combination with the Views page access "trick" when Page displays have identical path.

As far as I can tell, Node Relationships backref facility is always going to call the default view display anyway, not an access-specific Page (no matter what path):

http://drupal.org/node/767910#comment-2834422

So I don't think I can combine the strategy you suggest (known to work directly) with backlinks views using Node Relationships.

I've found where Node Relationships is overriding the view Page display paths.
http://drupal.org/node/767910#comment-2834412

@merlinofchaos

> So, should this issue move to that module?

Although there is little that can be done involving Views, please don't move this support request from the Views issues area, because it is about the interaction of at least 3 other formatted-backlinks-capable modules (Viewfield, View Reference, Node Relationships) with a (functioning) Views feature. I will open dedicated support/feature requests for each of those modules, and once I have a solution known to combine well with the Views feature, I would like to report it back here briefly for Views users. The ability to filter displayed fields by role is just as important for richly formatted backlinks as for regular views, and hopefully of interest to other Views users.

> Doesn't seem like much I can do about it.
No, nothing you can do, please just let it hang here though. Thanks for your input.