Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Sorry, but I am overwhelmed by tabs on my nodes - is this issued before - did i miss something in settings?
Fantastic module xxx
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | no_map_tab.patch | 839 bytes | aron novak |
| #2 | 338933_remove_tab_on_node_type.patch | 1.81 KB | alex_b |
Comments
Comment #1
alex_b commentedI agree. the map tab on nodes that aren't feeds needs to go. The way to do this is to add a access control callback to the menu callback. Anyone up to the task?
Comment #2
alex_b commentedThis patch should do it. Do you want to give it a spin?
Comment #3
simmoe commentedIm not so hardcore with the patch lingo - but if you can send me the whole .module file i can try it out
s
Comment #4
alex_b commentedit's really easy to apply ;)
1) copy patch to feedapi_mapper directory
2) change to feedapi_mapper directory, then execute:
3) patch -p0 < 338933_remove_tab_on_node_type.patch
Comment #5
alex_b commentedCommitted. Thank you for reporting.
Comment #6
alex_b commentedRolled out in beta3.
Comment #7
Anonymous (not verified) commentedThe map tab still appears on nodes with beta3 and the latest dev checkout. The feedapi_mapper_access_mapper is only called for the content type and not for individual nodes' local tasks. Should I open another issue or can we reopen this one?
I'll admit that I did try to fix this myself, but I'd need to pass the whole node to the feedapi_mapper_access_mapper function whereas the content type admin menu only passes a text string. Should I make a 'access callback' point to a wrapper function around feedapi_mapper_access_mapper for the node/%/map path? Or should I check the type on the parameter, so if it's string we check the string but if it's an object, we check the type property on the object?
Comment #8
Anonymous (not verified) commentedComment #9
aron novakSomewhy i don't have commit right on feedapi_mapper so i post a patch here.
It's generally problematic to call a 'private' function of another module, but the other case means duplicated code, i prefer this way.
Comment #10
aron novakComment #11
Anonymous (not verified) commentedMy name is bangpound, and I approve this patch.
It's problematic, but feedapi_mapper is dependent on the feedapi module. Maybe that function should be de-privatized?
Comment #12
alex_b commentedThe call to _feedapi_op_access() was not correct anyway: Only users with administer feedapi permissions can configure mapper.
This is what I comitted now:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/feedapi_map...
The per node access check goes through the same function as the per content type access check. This is more consistent and works correctly.