Advanced & tips

Those entries will provide more advanced information including access protection, tips and notice of side effects.

How to organize contents further?


Drupal taxonomy model allows you to also classify any Drupal content  into arbitrary or pre-defined tags defined by selecting "terms" from a vocabulary. To explain it in simple terminology, view this as a grouping of pages into a book: the book will be a Drupal self-generated static page made of individual documents created on your site and assigned a particular category (or term). Drupal Contents which may grouped according to items could be book pages, meeting entries, agendas, images, stories, etc... in other words pretty much any Drupal content. Note that each content (a book page for example) could have one or more terms associated to them allowing for several summary listing to be generated.  For example:
  • you may assign to a book page the  term computing
  • AND you may also assign to the same book page the term grid
  • Drupal will then generate a computing book AND a grid book with your page belonging to both.

Categories could be organized as a hierarchical structure (with sub-categories) but at any point in time, the hierarchy can be modified.

The default term on our site used to be the term computing [which obscured the computing related content and render the term meaningless] and this was altered to be the term unknown on January 24th 2008.

How to select a term?

The following picture shows the relevant box specific to our Web site. This should appear whenever you edit a page.

As you can see, below the Title and Parent association box, the STAR vocabulary appears.This is a list of pre-defined terms and the default is highlighted as "computing". You can select any other by one mouse click or using CRTL/right-mouse-click select additional terms for the page you will create or use SHIFT/right-mouse-click to select an entire range.

On a last note, the power of taxonomy goes as far as your choice of terms is relevant. If users start to assign all categories to any page, it would render this feature useless.

I would like to display code - How to do this?

Code can be displayed in filtered HTML or  full HTML. To display code, you have two solutions:

  1. Use the regular <pre></pre> HTML tags
  2. Use the <code></code> tag

Using the second, Drupal will format your code using the VIM-color module. Note that the <code> syntax can recognize code automatically from the first line like in

<code type="perl">
use DBI;
print "Hello world\n";

which will be displayed as

unlike the use of <pre></pre> which would display

use DBI;
print "Hello world\n";


WARNING: Note that switching between enable rich-text and normal mode while using <code> may scramble your formating. This was also noted in ... create a cross-reference to another page.


Adding TeX formulas to your pages

To add TeX formulas to your Drupal page, you need to enclose formula text with special tags:

[tex]a^2=b^2+c^2[/tex] [tex]x = \frac{-b \pm \sqrt {b^2-4ac}}{2a}[/tex]

will result in the following images rendered:




Should I use the WYSIWYG or not?


WYSIWYG are convenient as they allow seeing what you type and as it goes but they can also be annoying to advanced users as they change your characters as you type, trying to interpret everything as HTML. In Drupal, you may start the FCkEditor with the WYSIWYG ("rich text editor") or a "plain text editor". Before chosing any of those, please note the below
  • In ... quickly add a picture on a page, we gave a recipe which is unique to having the WYSIWYG enabled and would not be available in the "plain text" editor. If you plan to use the Image copy-and-paste feature, you will want to have the WYSIWYG enabled ...
  • Since the WYSIWYG changes your characters, it is hard to add content like the one explain in this I would like to display code - How to do this? - everytime you would edit the page, the WYSIWYG will ignore the <code> block content and add quotes where there should not be ... It is possible to work around by swithcing back to the plain text editor and fixing the content but it is annoying at best. If you itend to use the <code> feature a lot, you may consider disabling WYSIWYG
  • A similar warning (replacement of quote by &quote; where there should not be) has been noted in ... create a cross-reference to another page, a document not easy to create and modify with WYSIWYG on by default.
In short, if you use many of the advanced formatting features of Drupal rather than the quick "Filtered HTML" mode, you may want to start the edit session without the WYSIWYG enabled.

How to change the edit behavior and disable WYSIWYG by default?

You may alter the default behavior (start with WYSIWYG upon edit) as follows:
  • Go to your user profile (/STAR/user/XXX)
  • Select [Edit]
  • You will find a "Rich text editor settings"
    Set default state disabled and can play with the toggle and pop-up settings.
    To have a separate editing window for example, you will need to set toggle to disable and pop-up to enabled.

Access control and protections

There are many ways to provide access control and protection control in STAR's Drupal deployment. We try to support all those methods due to a feature requests from our users but the diversity may confuse other users - it is important to understand the scope and applicability of each and everyone of them. Please, read carefully.


  • Permissions are Drupal's native way to grant access to users with a "role" - roles are permission groupings that are set site wide. Users may have one more more "role" (roles do not have to overlap)
  • In the STAR deployment, we have a few "roles" explained below - note that the ACL module will also show those "roles" as well as allow setting fine grain user based ACLs (see the next paragraph for precisions)
    • Anonymous users  - this is any user not logged into the system. Typically, access are very restricted. They can view public pages, see agendas, guess there are attachments but cannot see comments or download documents attached to pages
    • Authenticated Generic - is a special group only a few "guest" users belong to. The access are similar to anonymous users but they can access agenda entries, see the comments (and can comment themselves) and see attachments. They do not have access to the voting API, cannot create blogs or pages, ...
    • Authenticated user - this is the default "role" for all STAR users. This allows manipulating pages (create, modify), creating blogs (create, modify, delete), access voting API, add attachments to agendas - However, standard user in STAR cannot modify pages from another user and cannot delete content. You need to be in the last role for that
    • Authenticated usr lead - is the near highest role in the STAR Drupal system. This is granted to specific management team's members, the PWGC during their term and software sub-system's coordinators but not other users. Even though both categories have additional rights, best judgment is required before a privileged action is taken.
      In addition of all of the above, those power users may create agendas (conferences), repeat meetings, delete pages (hopefully, they took note of this FAQ and would use that wisely), have more options for image upload, are able to submit news, revert revisions, approve STAR presentations publications and thesis module submission (best to PWGC and PAC not others).
    • Site admin - have additional privileges allowing changing the look-and-feel of Drupal, delete any blogs and any pages, delete revisions, delete polls, alter CAPTCHA, masquerade as any other users, modify menu items and many look-and-feel (theme and configurations), administer STAR modules, access usage statistics. This "role" is only granted to a handful of maintainers.
  • A note that the site administrator can alter and administer any content
  • Permissions are there for a reason - even with a few power users, we have seen many cases where pages from another user were modified (without that user being informed) sometimes just due to a sudden urge for cosmetic preference fixes. Or too quick thinking deleting pages and content created problems for others not finding the documents later on.

Groups (Organic Groups = OG)

Groups are ways to bundle pages under a single banner and grant  its members wide access to all documents under that group. Groups may have public or private documents.
  • Posts without any OG group assignment are always public and hence, falls under the "permissions" access rules.
  • A document or page may belong to one more group. If so, the page added to an OG may be public or private. The attribute is NOT set automatically and its default is public. However, an OG itself may have global settings altering the behavior in a global way (see below for more information).
  • To add a page to a group, edit a it and check the list available in the menu "Groups". As soon as you click/highlight one group, the checkbox Public becomes interactive. If you want that document to not appear as a public document, unchecked that box.
  • A special OG was created in STAR's Drupal deployment - it is named the "STAR protected" OG and ALL STAR Drupal users are signed automatically to that group upon account creation. Use it to hide/protect document and pages from peering eyes. 
Note of caution: Please, be careful - if you have page B as a child of A but protect A against visitors view, B will not be accessible. Also, do not overdo it. We want our pages to contain useful information to visitors and use more appropriate content types (like blogs) for non-public documents while the main browsable pages contains useful information for visitors and STAR members alike.


Also, note the following features and attributes
  • A group could be set to any of the below attributes and the group administrator decides at first how a group should be. THose influences the way you subscribe to a group.
    • Open - membership requests are accepted immediately.
    • Moderated - membership requests must be approved.
    • Invite only - membership must be created by an administrator.
    • Closed - membership is exclusively managed by an administrator.
  • Each group as a stratup page listing all documents added to the group by inverse time order (latest first). This is also known as the group homepage. However, the group administrator chooses whether the new group homepage and audience are private or not. Defaults to private.
  • A group may be set to be private in its entirety - if so, the meaning is "all document in this OG can be seen  by members only". This setting has little sense for open groups (if membership requests are accepted immediatey, what is the point of setting the OG as private? The only reason would be to protect globally against non-authenticated user)
  • A group may have an XML news feed - if you have an XML reader, you may be conveniently informed of pages added to the group as new document" subscription" to the group are advertized this way (but only if the group owner decides to do so).

STAR specific

Groups are much more than allowing regrouping documents under an etiquette or making documents non-public. Groups are primarily used for document sharing within a "team".
  • In STAR's Drupal deployment, all documents under an OG are accessible (editable) by all OG members - BEWARE of this convenience (a group's owner would need to be explicitly aware of this fact)
  • There is at least one Group setting per PWG (if not, ask your PWGC to send the Drupal admin a note

The questions of the day

  • How do you know the Drupal Groups?
    On the left hand-side menu, select the line named "Groups". This will list all available Organic Groups. In case of the Software and Computing, and for illustration, a right hand-side menu would show either an action menu or a Subscribe button. The Software and Computing Groups allows automatic subscription but this MAY NOT be a general feature (OG owner may require approval).
  • How do I know a document is part of a Group?
    When a document belong to a group, an additional menu appears in the left hand side navigation menu. This menu also shows if you have the right add documents (create)

ACLs - fine grain access control

  • User may "Grant" Access rights to other users.
  • Those rights, if set, superseede the "role" as well as the "Group" but you should avoid adding Grants on top of "Groups" access as the multi-layer of protection and access control may interfere with each other.
  • Grants are based on either "Roles" or Drupal user. The three roles in blue as showed above will apear, then a selection box so you can select a user.
  • To add a user, put is user ID in the "Enter names to search for users" textarea and click search.
  • If a valid user ID was selected,  it will be displayed below - make sure you select "keep" ...
  • Now, you can set for each role and/or user the view and edit right.
    Note 1: Power users may also grant "delete" rights of the page to other users
    Note 1
    : Please DO NOT Grant edit privileges to "Authenticated Generic" unless you really know what you are doing (and/or plan to remove that grant later on). I can think of only one case you would want to do this: a review is ongoing and you want to allow a specific reviewers (an non-STAR chair who has the "guest" account information) to edit a document ...
    Note 2: If you grant access to a user, please make sure to at least set "View" to all three Authenticated roles. This will prevent negative interactions where the Grant module may supersede the access permissions due to a side miss-configuration.