This page relates to forum topic 62582, Access Control for Intranet/Private site. Please visit for more background information.

Note about Drupal 5
Last time I checked, the glossary module either didn't work for d5 or didn't work quite the same way. I also think the node_privacy_byrole was also not updated for d5. However, a similar approach to creating an intranet could still be used by incorporating other node access modules. For example, a slightly more complicated setup using Taxonomy_Access could provide the same type of functionality with a little different interface and would potentially be more flexible for some cases. FWIW, I currently haven't upgraded the intranet I built with this system to use d5, but I have added a calendar to the system and in the near future might update the whole thing with some additional functionality. At that point, I might just import the data into a new setup or find a way to upgrade. Hope that helps.

--Ryan

Description:
Very basic intranet site,suitable for small groups or small business. Geared towards documentation/knowledge management type of functions. More functionality and larger companies should probably look at other modules especially organic groups.

Purpose:
Provide a place for employees to contribute, maintain, and share knowledge/information as well as posting company policy/procedures. Some information is sensitive so it requires permissions to be restricted to a few appropriate roles. Of course, the entire site is protected from public view. Note: This site is separate from the company's public website; a different setup would be necessary to integrate the two. The basic access control requirements are:

• All pages are protected from public view by default (but some information, like the front page, can be made public)
• All pages have view and edit privileges by default to all users (wiki style if you will, and revisions should be maintained and accessible)
• Should be able to restrict edit privileges to certain roles/users for specific pages or groups of pages (only view access)
• Should be able to restrict view (and edit) privileges to certain roles/users for specific pages or groups of pages (no access)

Core Modules Used:

• Book
• Comments
• Help
• Menu
• Path
• poll
• Search
• Taxonomy
• Tracker
• Upload

Contributed modules:

• Freelinking
• Front_Page
• Glossary
• Node_privacy_byrole
• Print
• Statistics
• Taxonomy_menu
• URLFilter

What I did:

Access Control: I setup a few different roles, like SysAdmin, Management, Financial. Then anonymous users have no privileges at all and authenticated users have most privileges. Other roles have almost no privileges either, except for a few administrative privileges for SysAdmins. Then I used node_privacy_byrole to setup default privileges for each content type. Note that authenticated users have "permissions for permissions" by default as well, and by default all roles have both read and write permissions (except anonymous users).

I used the front_page module to provide a welcome screen to any random person that comes across the site and provided links to the corporate site. Then, (as part of the front_page.module), I set authenticated users to redirect to the "node" page - this allows "post to front page" to actually work. Note -I was glad to find I didn't need to enable anonymous users any permission to "access content" and front_page still worked - however, it does restrict the site just a little and makes it impossible to make any content inside the system viewable by the public. At the same point, this is how the site is supposed to work so I decided not to worry about it plus any information that should be available to the public should be published on the public website (yes that does include minor duplication of effort but worth it).

I setup the glossary.module and enabled the input filter in the default filter. I also used the urlfilter as well. I included the freelinking.module but it caused a few issues which I seemed to have resolved in an "ok" manner, by putting the filters at different weights. It goes html filter -> line break ->freelink->urlfilter->glossary. I'm still not 100% happy with the freelinking module and I might remove if i get any complaints from users. I mainly wanted it so they could easily link to other internal pages without needing html experience.

Used the print module and enabled it for authenticated users - also uploaded a different logo to use for the printed pages. Nothing important here.

I used the statistics module to give a rudimentary "tracking" of different users actions. Semi interesting to look at now as I can see what people are doing upon their first login and how they are exploring bits. Will probably not have much interest after the initial period unless I need to track "problems" - like an angry employee or something of that nature. There might be some better modules for this but since its supposed to be a fairly open system by nature its hard to "lock down".

I used Books for the more formal and static "policy/procedure" type of things and then used taxonomy and taxonomy menu for classifying and navigating the non-book pages. I created a hierarchical structure for classifications and made it a required field (no free tagging). I also created another vocabulary "Other" and enabled free tagging to allow people to add new terms and tags. I disabled this vocabulary in taxonomy_menu though since there will not be much structure to it. I also included a "project name" vocabulary that is also free tagging but is still part of the navigation thru taxonomy_menu. These three classifications should provide enough flexibility for my users while still providing some structure.

As part of the glossary, I also had to create a taxonomy vocabulary for glossary. (Note glossary.module creates its own menu entry, so I disabled the taxonomy_menu for the glossary vocab) Interestingly enough, when i created it I was required to tie it to a content type, but I edited to remove the content type tie and it bypassed that problem. (I didn't want "glossary" to be an option in the create content page). I also found out that "administer glossary" has no functional purpose so you can enable it or disable it with no change. I however wanted users to be able to add/edit glossary terms. To do this, you have to enable "administer taxonomy" which I didn't really like. The work around that I came up with is to add a menu item as a child to the glossary menu item and use the direct link to adding terms to the glossary taxonomy. Then I disabled the "categories" menu item under administration so that users wouldn't see it. Then I created a block with a link to the taxonomy administration page "/admin/taxonomy" and I left the title blank. Then I used the "PHP mode" to only show that block to the admin user (UID #1) but I could've easily modified that to allow any SysAdmins to see that block too. Here is the code in the for the block. (I modified this from the handbook entries on PHP scripts.)

global $user;
  if ($user->uid == 1) {
    return TRUE;  // block will be shown
  }
  return FALSE;

Other Misc:
I re-arranged the navigation menu to have all the navigation elements near the top of the list (better usability i thought). I disabled the freelinking menu item. Used bluemarine theme because it was semi-close to company colors and didn't want to do a custom them. Used the options to include logo and favicon.ico but disabled the search bar in the theme and chose to enable the search block on the left hand side. Also, setup site so only admins could create users (no registrations) and modified the email sent out upon creation. I removed the listing of the password initially created so as to make it more likely they will change their passwords upon login. I enabled clean urls, mainly to make it easier for internal communication of links not search engines. i also setup a cron run to make the search index work. Disabled cache (not needed) and changed files to be governed by drupal (small company so little overhead). Modified the search ranking a little.

Future Work:
In the near future I might add in the notify or subscription modules to allow for email notifications. I might also look at including the tinymce module but I wanted to see how the users responded to this first before potentially complicating things. I have also read there can be a few issues with Tinymce and the different filters and I didn't want to spend time debugging it just yet. I also might have to change my PHP memory if my users start wanting to upload large files, but I haven't modified it for now. In the longer term, I might consider adding other functionality like liquid wiki, organic groups, calendars, CiviCRM, or other features but only as site grows or people request them. The only other consideration would be if the company wanted to allow clients to have access to any of this information like project status or allowing clients to submit issues. This would require reworking the permissions a bit - I think it would be fairly simple to define a new role a "general employee" and move all the default permissions to that role. Then disable all access to "authenticated user" and define a separate role for "client" and provide whatever privileges are there (mainly just view permissions) and update the node_privacy_byrole information accordingly.

Wiki Possibility:
This site was also a prime candidate for a private wiki. I decided to use drupal for a few reasons. 1) drupal provides the ability to add other functionality down the like, like a company calendar or integrating CiviCRM to be used internally. 2) The wiki's I looked at all seemed to have one problem or missing feature that didn't quite fit for me (as a newbie to those systems). I narrowed my choice in wiki's to TWiki (which I liked a lot but seemed more than what I needed and seemed to have difficult setup), MediaWiki (lots of reports of it being difficult to secure since its primary audience is public wikis) and a few others like docuwiki, pmwiki, wikkawiki,wackowiki, and moinmoin. 3) I was more familiar with Drupal.