Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Users other than uid 1 can't edit CONTENTdm wrapper nodes, even when they have the appropriate permissions ('search CONTENTdm collections').
Data points:
- Granting 'administer nodes' permission does not grant editing permissions.
- It's not just a matter of the local tasks menu ('view', 'edit', etc) not appearing - going to the edit path manually results in an Access Denied error.
I suspect the issue is in contentdm_access – I will try a fix and post a patch.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 1334824-5-format.patch | 590 bytes | laken |
Comments
Comment #1
laken commentedIn my testing, when viewing an existing wrapper node, contentdm_access() is never being called with $op='update', only $op='create'. I'm not sure under exactly which conditions hook_access is supposed to be called with 'update' but I imagine it should be called when viewing the node, to determine whether to display the edit links. So I think there's a problem here. Not sure exact next steps, will return later.
Comment #2
laken commentedIssue is that nodes are forced to Full HTML format in contentdm_create_wrapper(), which user may not have.
Comment #3
markj commentedReason I chose Full HTML is that CONTENTdm items can contain <br>, which is not included in Filtered HTML by default. So, one of the configuration tasks should either be to add <br> to the Filtered HTML filter, or to grant access to Full HTML to roles who can create contentdm_wrapper nodes. Maybe adding <br> to Filtered is simpler? However, if the site admin changed the default from Filtered to Full, we'd still have to assign perms on Full, wouldn't we? Or do all users get perms to use the default input filter?
Comment #4
laken commentedIn our use case we cannot grant access to Full HTML format to users who can create contentdm_wrapper nodes, because those users are not trusted.
Interestingly, in this case it doesn't appear to be a risk for these nodes to have Full HTML format, even if the authors aren't trusted, because you can't edit the node bodies anyway. However, Drupal core enforces that if the node is in a format the user doesn't have perms for, user cannot edit the node, period.
In our case the only reason we need the user to be able to access the edit form is to assign taxonomy terms. If there's another way to do this – like somehow showing the taxonomy UI on the node view page rather than the node edit page, we can dispense with the need for users to edit the wrapper nodes. However, others may have use cases that require the user to edit the nodes, so I think we should fix the format issue and allow this.
Since any input format can be edited and altered in any way, you can't assume that Full HTML will necessarily permit
tags - that format could have been renamed and totally reworked. What if we just set the input format to the site default (which all users have access to) and note in README that
should be added to whitelist for the default format?
Comment #5
laken commentedBy removing explicit filter assignment, node gets created with '0' in the format column, which seems to indicate 'default' format (though I haven't found docs on this yet.) In quick testing, nodes so created are editable by the node author. Take this for a spin.
Comment #6
markj commentedAndy, you're correct -- from the top of core's filter.module:
// This is a special format ID which means "use the default format". This value
// can be passed to the filter APIs as a format ID: this is equivalent to not
// passing an explicit format at all.
define('FILTER_FORMAT_DEFAULT', 0);
So, I agree with your approach. I'll test and commit your patch, and add text to the README that the default input filter needs to allow <br>.
Comment #7
markj commentedOn second thought, I think I'd rather explicitly define $node->format = 0; so we can document why we've chosen the default. I'll test this and commit to -dev it if works same as your patch.
Comment #8
markj commentedFix pushed to -dev in commit 650e383.
Comment #8.0
markj commentedtypo edit