Posted by merlinofchaos on April 19, 2008 at 11:16pm
Jump to:
| Project: | Advanced help |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Right now all help is totally mixed together. The difficulty will be in the search system where we'll have to actually put the permission information in the database.
Comments
#1
Do I understand that you're talking about a "can read help text in section foo" type permission system? Something like the 'access' part of a menu item?
#2
Yes, something exactly like that.
#3
So I started rolling a patch that integrates advanced help into D7, and I added a 'help arguments' key to menu items. This takes exactly the arguments $module and $topic. Seems to me like we could piggyback on the menu item's 'access'. How does that taste you?
#4
That could be interesting -- you should note that this is one something Gurpartap who is working on help as his Summer of Code project could be very interested in, and he's already done some work porting this module to 7.x (as help.module). You should contact him before doing too much more as I fear there is duplication of effort going on here now.
That said your idea has a lot of merit and I think it could solve the access issue.
#5
Yeah, I toyed around with it before realizing that Gurpartap was doing the same. Will contact.
#6
#299050: Help System - Master Patch
I do not see any per section type permission system in the patch yet.
I started to use advanced help on the frontend of the website (help for users, not for admins), so a permission system is a much needed functionality for me now. Is there any quick solution (or idea) how to restrict the access on some topics?
#7
+1 on this feature. We must be able to disallow users to access module help (which is for developers), while allowing them to access site help (which is for users).
Subscribing.
#8
+1
A logical idea would be to optionally associate each entry in the .ini file with a permission (or list of). Thus, if I don't have the 'administer module' permission, I wouldn't see the help topics associated with 'administer module'.
This would tailor the help system to each user role and unclutter it for users with fewer permissions.
#9
That part is easy. The search integration part of it is the hard part. Search is waht makes permissions complex.
#10
+1 subscribing
need to be able to have help for non admins (people who can only add nodes should not be able to view the help for views)
#11
+1 Subscribing
One solution that I'm investigating is creating a "enduser help" module in the Advance Help format, and include both a permission and a hook_form_alter to route designated "end-users" to just the enduser module's help index page. Thought it'd be relatively simple to add this - but have been stymied by an index page that won't show. Posting the current implementation online to solicit ideas and suggestions:
<?php
function enduser_help_menu_alter(&$items) {
// View help topic index.
$items['admin/advanced_help']['title'] = 'Enduser Help';
$items['admin/advanced_help']['page callback'] = 'enduser_help_page';
$items['admin/advanced_help']['type'] = 'MENU_CALLBACK';
$items['admin/advanced_help']['access arguments'] = array('view only enduser help');
}
/*
* modify all help topics to administrative overlay
*/
function enduser_help_admin_paths() {
$paths = array(
'help/*' => TRUE,
'advanced_help/*' => TRUE,
);
return $paths;
}
function enduser_help_page() {
drupal_goto('admin/advanced_help/enduser_help');
}
/**
* Implementation of hook_permission()
*
*/
function enduser_help_permission() {
return array(
'view only enduser help' => array(
'title' => t('View only end-user help'),
'description' => t('User will see only the contents of the custom end-user help'),
)
);
}
?>