Hi,
I'd be curious to hear some recommendations for handling permissions and workflow for a very complex University site. This is a single site with over 20 sections for schools/departments - not subsites. Within each school/department there would need users who can add/edit content only in their section and other users who can approve/publish content in those sections.
In the past, I've set up pretty complex permission systems using taxonomy access modules that have worked well, but in those cases it was limited to under 10 roles, so it was manageable. I think any type or permission system that relies on roles would be too clunky, as with over 20 sections, that would be 40+ roles.
The site was original conceived to use domain access for this purpose, but many of the sections do not have subdomains, but are just 'sections' with content. I'm exploring Workbench access as a possible solution. but would love to hear what other have done and recommendations.
Thanks,
Sam
Comments
Workbench Suite FTW
I recommend Workbench Suite, including Workbench Access and Workbench Moderation. At University of Wisconsin-Platteville I built their current website using Workbench Suite for authorization and moderation. The website has over 100 "content sections" with over 200 "content stewards" but it appears to be one well integrated website. That said, since I left 6 months ago, the website has been horribly mismanaged and it is hard for me to look at it. But this solution worked great for 2 years before I left. I received a lot of compliments from content editors who had been very disappointed by previous efforts. I did a lot of research before implementing my solution, and the consensus seemed to be that Workbench Suite is the best authorization/editing/moderation/publishing solution for D7. You can find the website at http://www.uwplatt.edu and you can contact me if you have any questions.
-JV
Another Workbench Fan
We (Stony Brook University IT Dept,) also use the workbench suite (specifically access/moderation) 150+ editors across 50+ workbench teams. Our team sizes are small (3-6 people). Editors can belong to multiple teams. Nodes can have multiple workbench teams.
Workbenches can be assigned via menu hierarchy, but we use a taxonomy list (one term per team).
Teams can be nested:
-History (Department Head)
--American History (Faculty);
--Euro History
You can assign Roles to teams i.e. Site Admins belong to every team.
Bryn Mawr College is using
Bryn Mawr College is using Organic Groups to limit access to sections in a similar situation (one site containing all campus departments/offices eventually-- we're doing a phased migration into Drupal) and we're pretty happy with it so far. However, thus far we do not have approval workflows-- permissions were really the issue for us.
-Juliana
+1 for OG with workbench / workbench moderation
OG also integrates with workbench and workbench moderation using views so you can have users managing the publication workflow for their own 'section'. I would definitely consider OG.
Can you expand a bit on how
Can you expand a bit on how you used OG and WB together. Are you using OG for actual groups on the site or is it just used as a means of controlling access? I guess I'm trying to get at what OG provides that WB or WB access doesn't.
Thanks,
Sam
NMS: Drupal Training & Services
www.new-media-solutions.com/drupal-training
Greater Philadelphia Drupal Meetup
www.meetup.com/drupaldelphia
OG + Workbench Moderation
At Western Washington University, WWU, we have built this type of functionality with OG and Workbench access. Within each college every department is a group. The group members then can only edit the content that belongs to their department. Workbench moderation then allows certain individuals in the department to publish drafts that other group members write.
We find this patch necessary,
projects[og][patch][] = "https://www.drupal.org/files/issues/group_reference_token-2264759-17.patch"
I think the one difference
I think the one difference between workbench access (which I admit to only testing once) is going to lie in the workflow for adding content.
Here is what I do using organic groups:
Same as @theMusician each department is a group node - which is used as the landing page for the department as well as for assigning content to the group/department. In workbench I modify the views to be "OG aware" - so that for example if you are a member of a particular department when you add content it is automatically assigned to your group using entityreference_prepopulate and the OG reference field is hidden - which is nice from a UX persepective.
Another difference with using organic groups is that you lose the ability to do hierarchical access control - which the taxonomy based access control modules provide.
have used OG in the past;
have used OG in the past; these two are also interestingly simple options:
https://www.drupal.org/project/nodeaccess_nodereference -- if someone has access to the item referenced by a node, then they can have a configurable set of capabilities on this node
https://www.drupal.org/project/nodeaccess_userreference - give people access if they are listed in a user reference / entity reference.
Combining the two, you could have something called "section" as a content type w/ a user reference field, place all the people in that "section" to have part of that user reference. Then, whenever anything references that section for their content to be attached to, the users will automatically have read,write,delete level permissions (configurable).
Definitely worth a look cause I think it can be used very creatively.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/