We made the decision to restrict access to our site to authenticated members of our academic community. I have to admit that I do find myself a bit muddled on the whole issue of transparency / transparent life. Perhaps having been raised in the rural Midwest, and spending much of my adult life in downeast Maine - geographic locales where personal privacy is perhaps pathologically emphasized - has unduly influenced this ;^). When introducing blogging/journaling/portfolio production into an academic community, further issues come forward, and frankly, I’m confused by it all. The issue of the transparent life has come upon us rather abruptly as transportation and communication technologies have become more sophisticated and available; it will be the task of the next several generations to sort out the hows/whys/ifs/whatnots/inevitabilities of this.

I’d love to see some discussion on this topic. I’m sure there’s a lot of it out there on the ‘net. Thanks to folks taking the transparency option :^).

But anyhow -

In Adminster > Access control, I’ve given “anonymous user” no privileges, including no access content privileges in the node module section. Non-logged-in users will see only an “Access denied” page with login fields.

Prior to denying “anonymous user” node module > access content privileges, it is important to assure that you will not lock yourself out of the site! This is easy to do with Drupal (or perhaps I’m just particularly skilled at this …), and you’ll find a lot of desperate “help” messages in the Drupal forum on this issue. (You can get to a login page using http://yoursite.com/?q=user , if you are so unfortunate). But before denying “anonymous user” access, activate the LoginToboggan module; then go to Administer > User management > LoginToboggan, and set the Present login form on access denied (403): radio button to enabled.

I have been playing around with Drupal 6.x. It is not yet ready to go for this application, as several of the necessary modules have not yet been made 6.x-ready. But its granular permissions structure may permit greater flexibility - permitting users to elect to make some content world-visible while holding other content within the authenticated-user community. It’ll be fun to mess with when module development catches up.

Access control for “authenticated user” should be straightforward. In the node module section, I’ve given permission only for access content, create group content, and edit own group content. In the Aggregation module section, I’ve given permission for manage aggregation feeds, manage aggregation items, manage own feed items, and view aggregation items. Users can post only 2 kinds of content - Blog posts, and imported feeds & feed items from their external blog. This reflects in part a decision to keep it simple. As a postgraduate school, we have many students of the cyberphobic demographic; too many options could discourage use. (also - the Books node is reserved for administrator use for Help pages; the Stories node is reserved for administrator use, for the 2nd aggregation module - feedapi - to aggregate news feeds for the socially-rated news section of the site).

I’ve given creation and attachment permissions for audio files in the audio and audio_attachment sections, so that users can post streaming audio into their blog postings.

User use authorship needs to be enabled in the Authorship section, to associate full names with posts, rather than usernames (this option will be configured in the Authorship module admin).

Override node publishing options needs to be enabled in override_node_options module section, to permit users the option of posting unpublished posts.

Other permissions should be intuitive, but I’ll visit a few of these in turn as I get around to discussion of specific functionalities of the site.

Leave a Reply