I've spent weeks so far trying to come up with a CMS that will support my requirements. Requirements that seemed to me to be fairly simple. I've tried several systems so far and Plone seems to be the closest fit, but it seems so cumbersome to work with.
Can Drupal handle my simple intranet site with these requirements?
1. I want login access to view content
2. I want only content pages, sub pages, menus, sub menus and files (keep it simple)
3. I want page and menu visibility to be controlled by user group or role
4. I want page creation, update, file creation, update to be controlled by user group or role
Sounds pretty simple to me. Maybe I'm looking for the wrong type of tool? Any assistance would be appreciated. Now if you're interested in what I'm doing, I'll give a real world example below.
I want a company intranet site (internal only)
I want a selection (menu) for each company function (HR, IT, FINANCE...)
I want each department to be able to manage their own section and not be able to muck with anybody elses section; I'm dealing with some non-techies so it's got to be easy to create pages and upload files.
I want unauthenticated users not to be able to do anything but login, and the authenticated users will probably be allowed to read/download anything (but if some content could be restricted -- great!)
So am I barking up the wrong tree with Drupal? Should I just have my php developers make something themselves?
Thanks for the help.
Comments
actually have something like this...
one of my installations is almost exactly like this, so it is do-able. the question is, what do you call "easy" for the end-user; ranges from "able to do some html" to "it should read my mind"? that, for me, made drupal doable (you will have to wade through the wysiwyg arguments on your own; sorry!). some training/reprogramming of select brains involved, but it can work. and, it actually handles "deliverables creep" pretty well ("great! now, what about..."). oh, and i am not a programmer, so think what you can do!
just one opinion. good luck!
(no title)
Most of these thing can be done in several different ways without much customization, by adding some specialized modules.
1. With only core Drupal you can configure it so that a visitor either sees everything or nothing at all. By adding an access control module you can achieve finer control over what someone can see.
2. If by "pages/subpages" you mean a hierarchy of pages, you can achieve it either using "books" (a hierarchical structure with parent/child pages and navigation between them, like the Handbook that you see here on the top menu) or just by using comments under the pages. If by pages/subpages you mean pages with different embeded parts, this is also easy with some modules. Menus, sub-menus and file uploads are also available in many ways.
3. Page visibility and menu visibility are also easy by using some modules.
4. This is possible in several ways. The most "read-to-use" module for your case is perhaps the organic groups module. "Organic groups" are subscriber groups which can be private and have an "audience". So, they look like your departments. The OG module is used in http://groups.drupal.org, although most groups have been set to public there.
There are also alternative ways to control viewing/editing/creating access by "user role", For example you can create different "content types" for each department and allow a department's members (a "user role") to use only their own content types. Or you can separate the departments' content by allowing a department''s members to tag them as belonging to some category.
To upload/control files, authorized users could just attach them to a special content type (something like a cover sheet) and then the files could be controlled by controlling that cover sheet, same as with the rest of the content. The files could be places outside the web root of the site ("private download method"). There are also more fancy ways by using additional modules to browse directories, but probably the standard method is the most secure if you want to keep the files under control.
Well, that probably sounded incoherent if you are new to Drupal, but the bottom line is that it can be done without much difficulty.
More details please...
Ok, you've convinced me that I can do what I'm trying to accomplish. I've dowloaded version 5.x (it seems to have the most support modules right now). I've looked through all the modules and downloaded the ones I thought might get me what I wanted.
So far, no joy though. I thought the "Organizational Infrastructure" module would help, but it doesn't appear to do what I need.
My big problem is figuring out how to give the permissions out.
Here's the way I have it set right now.
I've given no access to anonymous users (only login block)
Once logged in, they can see all the menus (I want everybody to be able to read everything -- at least for now)
Some users are tagged with specific roles (HRAdmin, DEVAdmin, FINAdmin, SALESAdmin...), I want these people to be able to manage administration (adding/changing content, uploading files, adding menu options...) for the pages that are under their menu hierarchy (HR, Development, Finance...)
The goal is to have non-techie users from Finance and HR to be able to change pages, upload files (expense forms, HR documents etc) on their own without having to use IT resources.
I've tried organic groups, several access control modules, organizational infrastructure, views, and lots of others. So far, I haven't found any combination that will do what I want.
Can somebody give me a "recipe" that I can use?
Thanks!!
Good start
Good on you for having a poke around and getting that far ;)
I think Organic groups or Taxonomy_access is what you want for your task.
The thing to understand is that menus are just a presentation layer, and not (unless there's a module out there) usable to control permissions. It's a bit of an all-or-nothing thing from my experience. This feels a bit anti-intuative when you are used to controlling access based on subdirectories etc, but path/urls are also just cosmetic additions, not intrinsic structural properties.
You need to embrace taxonomy to sort all your posts into top level 'sections' as well as placing pages in a menu structure. Then manage access based on these sections.
About now, I advise educating/trusting your users a little bit to not put pages in sections that are not theirs ;-)
Not perfect, but ultimately quite powerful. Handy for branding/theming different sections also.
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
(no title)
One way to set up your sections is to use taxonomy categories, and then you can set up permissions for them using the Taxonomy Access Control (TAC) module http://drupal.org/project/taxonomy_access.
1. Create a vocabulary containing your site's sections as terms, and make this vocabulary "single-selection", "required", and applicable to the content types you want.
2. In the admin/content/taxonomy_access page, set up the permissions for the user roles you want. You can allow some user roles to "Create" content tagged with those categories (sections), and deny this permission to the other roles. So, other users won't be able to tag their content with those categories. You can also give some user roles "Update" and "Delete" permissions for a category (section), in which case they will be able to edit *any* content under that category (even if it was authored by someone else).
3. For creating "section pages", you can use either taxonomy listings (taxonomy/term/nn, where nn is a category ID), or views (Views module -- http://drupal.org/project/view), again based on the categories.
Another way is the Organic Groups (OG) module http://drupal.org/project/og. In this case you won't use user roles but subscribers to different groups (similar to the http://groups.drupal.org site). You can make the groups private so that only its members can post in a group. This solution is more "vertical" and some find it easier as long as the requirements fit its model. There are also several helper modules which extend its functionality (with names like og_something -- you can find them in the downloads section).
It is safer not to mix these two approaches, because content which is restricted by one can be made accessible by the other if you don't study their interactions carefully.
@cog.rusty - If you use the
@cog.rusty - If you use the OG module, can you have groups that are public but still allow non-group members to subscribe to the content that gets posted into that group?
Also, you said
4. This is possible in several ways. The most "read-to-use" module for your case is perhaps the organic groups module. "Organic groups" are subscriber groups which can be private and have an "audience".
What do you mean by "and have an audience"?
I would basically like to have a city website where departments are groups and citizens can subscribe to the content posted in the group. Then departments could send out notifcations to the subscribers.
Question is:
How would I restrict citizens from posting into the department groups?
How would I restrict what staff members can post into the department groups?
How would I restrict what content types are available to post into the department groups?
OG can do it
I think by "and have an audience," @cog.rusty meant that each "group" created using the Organic Groups module has its own members. The members of that group are the primary "audience" for the content specific to that group. I've heard OG described as a way of creating "buckets" that contain both users and content. If you want to see a good example, try groups.drupal.org. It has groups for a wide variety of topics, e.g., "Drupal users in Wisconsin"; "social networking," etc.
OG is configurable to support various ways of managing membership in each group, confidentiality/privacy, etc. For example, a group can be set up so anyone can join it, or it can be exclusive so people have to be invited in order to join. You can set it so that only members can view the articles (nodes) related to that group. Alternately, you can set it so that anyone can view the articles.
I think it should be possible to configure Organic Groups to do all of the things that you've described.
----------------
Customer Support Engineer, Granicus
https://granicus.com