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

  • 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.

Attributes

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
     
  • ATTENTION:
    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.