Posted by Simon Georges on March 5, 2011 at 12:00pm
12 followers
| Project: | Workbench Access |
| Version: | 7.x-1.0-beta5 |
| Component: | User interface |
| Category: | feature request |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | #d7ux |
Issue Summary
Hi,
The workbench suite is awesome ! I was just wondering... Is it possible to use Workbench Access by content type ? What I mean is, for example, I could want to avoid using Workbench Access for the newsletters (their creation would directly limited by role and core permissions).
Anyway, keep up your magnificent work, it will be used !
Comments
#1
No configuration yet (though it's in the plan). If you are comfortable with writing code, you can do this now:
From the api file:
<?php/**
* Allows modules to alter user privileges.
*
* Standard drupal_alter() hook to allow modules to modify the sections
* that a user is allowed to edit. This hook is largely present to allow for
* complex handling of content type permissions.
*
* @param &$access
* An array of access data, keyed by the access id. Passed by reference.
* @param $account
* The active user account object. Note that this object may also be altered,
* since objects are implicitly passed by reference. Normally, you should not
* alter the $account object with this hook.
*/
function hook_workbench_access_user_alter(&$access, $account) {
// Make content editing specific to assigned node types.
if (empty($account->workbench_access)) {
return;
}
$types = node_type_get_types();
foreach ($access as $id => $data) {
$access[$id]['update'] = array();
foreach ($types as $type => $value) {
if (user_access("edit any $type content", $account)) {
$access[$id]['update'][] = $type;
}
}
}
}
?>
Currently, the permissions for a user pass the $id permissions as an array with one entry 'all'. You can alter this behavior using the above function.
<?php$access[$item->access_id] = array(
'view' => array('all'),
'create' => array('all'),
'update' => array('all'),
'delete' => array('all'),
'preview' => array('all'),
'revise' => array('all'),
'publish' => array('all'),
);
?>
Then in the actual access check, we run this:
<?phpif (in_array('all', $account_access[$id][$op]) || in_array($type, $account_access[$id][$op])) {
return $id;
}
?>
So if you had a conditional statement, you could write something like so:
<?php/**
* Implements hook_workbench_access_user_alter().
*/
function custom_workbench_access_user_alter(&$access, $account) {
// Make content editing specific to assigned node types.
if (empty($account->workbench_access)) {
return;
}
$types = node_type_get_types();
foreach ($access as $id => $data) {
$access[$id]['update'] = array();
foreach ($types as $type => $value) {
if (user_access("edit any $type content", $account)) {
$access[$id]['update'][] = $type;
}
}
}
}
?>
This code, for instance, restricts editorial access according to the core 'edit any TYPE content' permission by section and should just work if you put it in a custom.module file.
If you aren't comfortable writing code, what I really need is a good UI pattern for setting these permissions. Should they go on the Permissions page? The Content Type configuration page? A custom Workbench Access settings page?
Ideas welcome.
#2
Wow, what a complete answer ! Thanks a lot (I'm indeed ok with writing code).
Regarding the UI pattern, I was first in favor of a custom Workbench Access page, to allow quick configuration, but then I thought than the more content types you have, the more this page would be a bad idea. What's more, I think there's only a few content types that would be concerned by workbench access (although the main ones (pages, articles)). So, by starting with a settings on each content type page, unchecked by default, there would only be some clicks to have it working.
I see that Workbench moderation already has a setting in the content type page, I propose to do the same (like the Simplenews example in the attached screenshot), with just a "use Workbench Access for this content type" checkbox.
I'll try to work on that as I'm sure I'll need it on the projects I will work on in the future, but I'm not expecting to do Drupal 7 work before one or two months. If I'm faster than you anyway, I'll post it there.
Again, thanks for all the help.
#3
A patch to the main module is perfectly fine, btw...
#4
I'd really like some guidance from the UX team on this, actually.
#5
would love to see this feature eventually implemented !!
+sub
#6
Any ideas on how the UI should be formatted?
#7
I agree with Simon Georges in #2. A simple use case would be excluding all Webforms from Workbench Access.
Having a single location to include/exclude a content type in the access tree like this would be ideal.
#8
Personally, I really hate the "let's spread the configuration around to each content type config page" approach. I suppose we should do that and have a dashboard/overview screen that compiles all the settings as well.
#9
Thanks agentrickard for the extensive documentation.
+1 to #8
Should this overview screen be a generic function, so other module's settings could use it as well?
Also, I like #2: "So, by starting with a settings on each content type page, unchecked by default, there would only be some clicks to have it working." This would mean enabling the module would not have the effect of immediately blocking all content editing access.
#10
I am really looking forward to this feature. I like the idea of configuring this on the content type configuration page and agree with gaele.
#11
Sub, I hope to be able to contribute some UI/UX work/recos here.
#12
I think this one's pretty straightforward. It's #1155692: Allow per-section CRUD permissions that needs serious UI / UX design.
#13
Pretty simple patch. Adds an option to the content type edit form and to Workbench Access configuration.
Any thoughts about the use of the fieldset? Should it not be collapsed?
#14
Screenshots of the form elements.
#15
Revised to use 'enforce' consistently on the UI.
#16
Now with a shiny new test.
#17
After I applied this patch I unchecked the article content type. I then went to node/add/article and the Workbench Access select list appeared in the form. I don't think that's the intended behavior.
Also existing nodes article nodes reported in the WB message block the sections to which they had previously been assigned. While I do not think nodes should be removed from their sections on a database level, I think functions that would act on that information can check if the content type is still one on which Workbench Access acts.
#18
Revised patch.
#19
Need to reverse the order of IF statements in the block.
#20
I think the messages from Workbench Access should be suppressed when on a content type not controlled by Workbench Access.
#21
In the newest patch, they should say "[Content type name] pages are not under access control".
That might be over-communicating, but it seems important.
Another question: How does this affect the dashboard Views?
#22
More TODOs:
1. Implement hook_node_types_update().
2. Implement hook_node_types_delete().
3. Hide the field widget on Content Type manage fields screens if disabled for that content type.
#23
Scratch items #1 and #2. They aren't needed. Node module handles that.
/me notes that @davereid was actually wrong about something....
#24
Proper hiding of the field widget.
#25
And a patch that removes restricted node types from Views and other elements.
Bumping to major, since this is a release blocker.
#26
I think there is a problem with the query method in workbench_access_handler_filter_access.inc
I have three content types on my test site: article, page and news. Workbench Access is configured to ignore article nodes.
Here is a query that Views produces when using this filter.
SELECT node.title AS node_title, node.nid AS nid, node.type AS node_type, node.status AS node_status, users_node.name AS users_node_name, users_node.uid AS users_node_uid, node.changed AS node_changed, node.uid AS node_uidFROM
{node} node
LEFT JOIN {users} users_node ON node.uid = users_node.uid
WHERE (( (node.status = 1 OR (node.uid = 1 AND 1 <> 0 AND 1 = 1) OR 1 = 1) AND (node.nid IN (SELECT DISTINCT workbench_access_node.nid AS nid
FROM
{workbench_access_node} workbench_access_node
WHERE (workbench_access_node.access_id IN ('news', 'page', '20', '21', '22', '23', '24', '25', '26', '27')) AND (workbench_access_node.access_scheme = 'taxonomy') )) AND (node.type IN ('news', 'page')) ))
ORDER BY node_changed DESC
LIMIT 25 OFFSET 0
This query produces no results even though there are page nodes in the appropriate WB Accesss taxonomy. It looks like the problem is that second where clause. If I comment out this line:
$this->query->add_where(0, "$node_table.type", $allowed, 'IN');Then I do get results. However, I also get results of article nodes that were assigned to these sections before article was disallowed from WB Access.
#27
Interesting. That wasn't happening on the Workbench views, but only on a new custom View.
This patch moves that query element to the subquery, which is likely where it belongs.
#28
Thank you for this. Exactly what I needed. Normally I have a menu with some views-pages, and the rest of the menu-structure is created with taxonomy_menu.
So the main menu could be:
main_menu
- home
- views-page-listing news
- views-page-listing events
- taxonomy-term topic1
-- taxonomy-term topic1.1
- taxonomy-term topic2
- taxonomy-term topic3
I applied the patch and it sems to work (did not do anything with views).
#29
Thanks @avdp.
One more review to go, and then we can commit.
#30
Queuing to review
#31
Minor re-roll.
#32
Re-roll to fix tests against head.
#33
Committing, since tests pass.
#34
Automatically closed -- issue fixed for 2 weeks with no activity.