Can a role access the node_ref field, if they do not have permissions to create the referenced node type? The permission access on the referenced node is the only thing I can see different between this and other node_ref fields I have created. ---Ashford

Drupal 6.14
CCK 6.x-2.6

  1. CCK type: archive_stats
    • A record of each volunteer's YTD and Prev Years totals.
    • Only Admin can add/edit/delete.
    • This is the node I am trying to reference in myhours.
  2. CCK type: myhours
    • A Volunteer enters their data for each activity.
    • user_reference_field (It works.)
      Use a Views list. Set the CCK default for the field with PHPcode and $user->uid.
    • node_reference_field for archive_stats. (It works for Admin only.)
    • What I've tried and the results.

      Select Options Widget: Widget narrows down to 3-5 characters and displays no options.

      Create a Views list for the OptionsWidget and give the Volunteer role access to the View. Same results as above.

      Fill In Widget: Start typing and the icon never starts spinning, like it normally does when searching.

Summary

This issue lacks a more drupal friendly description and it may be confusing for maintainers and developers to even understand what's going on. So, IMHO, maybe the following can be useful:

The problem here seems to be that CCK validation checks if the acting user has access to the referenced node and, if it hasn't, it prevents saving with the «this post can't be referenced» message.

This behaviour is wrong because the acting user hasn't and shouldn't have access to the referenced node or the referencing field. Instead, the reference was left there by and for administrators (or other kind of users in sites with node_access restrictive modules) and shouldn't be seen, altered or validated by normal user's editing.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Ashford’s picture

Status: Active » Closed (fixed)

I generated a test site and gave the Volunteers permission to create the referenced node type. It did not fix the problem.

Apologies to the Views Issues folks. I posted before thinking that I could test it myself. The brain is mushy after days and days of troubleshooting. Marking this as closed until I can produce further information. ---Ashford

Ashford’s picture

Status: Closed (fixed) » Active

Turns out the Role selecting the Referenced Node does need permission to Edit the referenced node type.

Is there a way around it? I don't want the Volunteers editing their own statistical data.

markus_petrux’s picture

Status: Active » Postponed (maintainer needs more info)

If you want to deny access to edit the node reference field in myhours that point to archive_stats, then I think you need Field Permissions.

Though, I'm not sure to understand where the problem is exactly.

Ashford’s picture

I will try to explain better. The problem is that I cannot allow the Volunteers to edit the archived totals; except by editing their current year's My Hours nodes.

The Volunteers record their activities and hours using content_type: My Hours. I do not want the Volunteers to edit their totals, except by editing/deleting their My Hours nodes for the current year.

---After each My Hours post/edit/delete, a Drupal Rule calculates the new YTD totals and updates the Archive Stats fields. That is why I need them to select their name (the node_ref_archive_stats list).

The YTD totals and Previous Year totals for each Volunteer are stored in content_type: Archive Stats and maintained using Rules.

---I use an archive_stats View to show the Volunteer their totals.
---The historical data from previous years cannot be altered once reported to our State Coordinators.

Access Permissions
---My Hours: Volunteer can add/edit My Hours for the current year records.

---Archive Stats: Records-keeper can add/edit any Archive Stats nodes. Most maintenance is performed by Rules.

yang_yi_cn’s picture

Title: Can a role access the node_ref field, if they do not have permissions to create the referenced node type? » user with content permission to view/edit node_reference field cannot save node, "this post can't be referenced"

I've the same issue and find some other people have similar problem like #287286: Validation error when saving node reference field content during cron, so I'll try to explain how to reproduce the issue and my workaround.

yang_yi_cn’s picture

Title: user with content permission to view/edit node_reference field cannot save node, "this post can't be referenced" » user without content permission to view/edit node_reference field cannot save node, "this post can't be referenced"
yang_yi_cn’s picture

Let's think about this scenario:

A site has 10 node, nid from 1 to 10.

There are 2 content type, A and B.

node 1~5 are content A, node 6~10 are content B.

There's a node reference field in content B can refer to any of content A. Let's call this field "node_ref_a".

Content permission module is enabled. And user "test" doesn't have any permission for field "node_ref_a".

However, user "test" does have the permission to edit content type B. So when he edit a node (type B), he cannot view the field "node_ref_a" on the node edit form.

==========All the above works fine, and now the problem comes =====

1. user "test" created a node (type B)
2. admin user make this node refering nid 1~5
3. admin user delete node 2
4. user "test" try to edit the node, still can't see the node reference field, but get "this post can't be referenced" validation error and cannot change anything else on the node.

yang_yi_cn’s picture

my work around is like this

(nodereference.module)

/**
 * Implementation of hook_field().
 */
function nodereference_field($op, &$node, $field, &$items, $teaser, $page) {
  switch ($op) {
    // When preparing a translation, load any translations of existing references.
    case 'prepare translation':
...
      return $addition;

    case 'validate':
// workaround start
      global $user;
      if (module_exists('content_permissions') && !content_permissions_field_access('edit', $field, $user)) {
        return $items;
      }
// workaround end

      // Extract nids to check.
      $ids = array();
     ....
yang_yi_cn’s picture

Status: Postponed (maintainer needs more info) » Needs work

For user with full permission, the form will be re-populated with only the valid values, so saving is not a problem.

But, when the test user try to save a node reference field with value "1,2,3,4,5", as node 2 has been deleted, the "_nodereference_potential_references" returns only "1,3,4,5".So it cannot pass the "validate" in nodereference module,

As the test user doesn't have the permission to edit this field, the form element is not getting generated, and nodereference_allowed_values() is not getting called during the node edit form generation. So such kind of user will always get the validation error and cannot edit their posts any more.

yang_yi_cn’s picture

So my workaround is, just return without checking anything for the validation operation, if the user doesn't have the permission to edit the field. I don't know if there's other potential problem, but it works for me.

John Pitcairn’s picture

Hm. Subscribing.

grzegorz.bartman’s picture

I solved this problem using hook_form_alter and #access parameter for nodereference field

Exploratus’s picture

hmmmm... this should be addressed with the module. I have some referenced that are only for administrator eyes, and it is creating problems for my regular users.

Exploratus’s picture

#8 worked for me.. But I still think this should be addressed permanently.

Ashford’s picture

Thank you for your suggestion. I can understand your logic in the code; however, I do not know how to write code very well. I assume the (...) means these are parts where you added custom code lines that work just for your web site. I would not know how to do that.

Encarte’s picture

Issue summary: View changes

new summary, more drupal friendly

Encarte’s picture

Version: 6.x-2.6 » 6.x-2.9
Category: support » bug
Priority: Normal » Major

In view of the new summary I left at the top, I'm changing this to bug status and major priority, since it tempers with people's data even when only CCK and core are involved. It can cause strange situations on a site where administrating users have nodereference fields that shouldn't be accessed by normal users, leading to the need of deleting information (remove the nodereference field) or freezing nodes (normal users won't be able to edit them).

Encarte’s picture

yang_yi_cn’s picture

recently upgraded one of my old project and faced this problem again! (the upgrade overwrites my local patch). It's surprise to find that this is still not committed!

Rolling a patch using the #8 against 6.x-2.9

yang_yi_cn’s picture

Status: Needs work » Needs review
splash112’s picture

Status: Needs review » Reviewed & tested by the community

Works and hope it can be commited

splash112’s picture

Issue summary: View changes

signing