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
- 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.
- 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.
Comment | File | Size | Author |
---|---|---|---|
#18 | 632914-8-node-reference-permission.patch | 580 bytes | yang_yi_cn |
Comments
Comment #1
Ashford CreditAttribution: Ashford commentedI 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
Comment #2
Ashford CreditAttribution: Ashford commentedTurns 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.
Comment #3
markus_petrux CreditAttribution: markus_petrux commentedIf 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.
Comment #4
Ashford CreditAttribution: Ashford commentedI 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.
Comment #5
yang_yi_cn CreditAttribution: yang_yi_cn commentedI'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.
Comment #6
yang_yi_cn CreditAttribution: yang_yi_cn commentedComment #7
yang_yi_cn CreditAttribution: yang_yi_cn commentedLet'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.
Comment #8
yang_yi_cn CreditAttribution: yang_yi_cn commentedmy work around is like this
(nodereference.module)
Comment #9
yang_yi_cn CreditAttribution: yang_yi_cn commentedFor 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.
Comment #10
yang_yi_cn CreditAttribution: yang_yi_cn commentedSo 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.
Comment #11
John Pitcairn CreditAttribution: John Pitcairn commentedHm. Subscribing.
Comment #12
grzegorz.bartman CreditAttribution: grzegorz.bartman commentedI solved this problem using hook_form_alter and #access parameter for nodereference field
Comment #13
Exploratus CreditAttribution: Exploratus commentedhmmmm... 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.
Comment #14
Exploratus CreditAttribution: Exploratus commented#8 worked for me.. But I still think this should be addressed permanently.
Comment #15
Ashford CreditAttribution: Ashford commentedThank 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.
Comment #15.0
Encarte CreditAttribution: Encarte commentednew summary, more drupal friendly
Comment #16
Encarte CreditAttribution: Encarte commentedIn 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).
Comment #17
Encarte CreditAttribution: Encarte commentedRelated problem in D7: #1352690: The widget should properly handle references to entities the user do not have access to
Comment #18
yang_yi_cn CreditAttribution: yang_yi_cn commentedrecently 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
Comment #19
yang_yi_cn CreditAttribution: yang_yi_cn commentedComment #20
splash112 CreditAttribution: splash112 commentedWorks and hope it can be commited
Comment #20.0
splash112 CreditAttribution: splash112 commentedsigning