Permissions
We'll cover the permissions for a core Drupal install here, and for the add-on modules in the appendix.
Block module
The block module is for creating the blocks that can be placed in various regions on the site. The permissions settings will depend on who will be administering them—these particular permissions don't affect their viewing. With this site, the site owners will not be performing site administration themselves, so we will leave those permissions to User 1 (the super admin) and not assign them to any of the roles.
|
block module | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
administer blocks |
0 |
0 |
B | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
use PHP for block visibility |
0 |
a |
At this point, the site is not making use of comments, but we will set permissions in an anticipatory fashion. We'll allow all users to read comments. Anonymous users have no standing to post comments, so we'll limit that capability to subcontractors (authenticated) and management, and allow management to do so without approval. Administering comments is a content administration ability rather than site administration, so we'll give management permission to do that. 
Contact module The contact module has two parts; contacting other users and giving feedback to a central user or users, who will receive the messages. The site will not enable user-to-user contact, so we will assign permissions in the context of providing site feedback. To that end, all roles will be given the permission to access the feedback form, but administration of that form will be retained for User 1. contact module access site-wide contact form administer site-wide contact form Content module The sole permission under the content module is the ability to use PHP input for field settings. There is a warning shown regarding this ability, which should read 'Really Really Really Dangerous' instead of simply 'dangerous.' We'll retain this capability for User 1. content module Use PHP input for field settings [dangerous - grant with care] Node module The node module permissions affect the creation, editing, deletion, and administering of content. The list of permissions is long, particularly because we have a number of custom content types. They provide not only the ability to create, each individual content type, but also the ability to edit and delete them, to segregate performing that action on the user's own content, and content without regard to its creator. We're going to allow all users to view (access) content. The administering of content types we will reserve for User 1, but the administering of the content itself, nodes, we will grant to management. With regards to individual content types, there is no reason for management to be creating new Page or Story content, since Story content isn't being used, and the Page content to be used has already been created. Also, there only needs to be one About_us content entry, and creating another could lead to issues if both are published, so we'll not grant creation permissions for any of the three. Other than those, we'll allow management to create content. Subcontractors need to be able to create Sub content, as well as Profile content, so we'll grant authenticated users those permissions. Keeping in mind that subcontractors are not yet registered at the point that they complete registration, we will also permit the creation of Sub content by anonymous users. We'll allow management to delete any content that they have the ability to create. We'll also allow them to edit all content, and allow subcontractors to edit their own Sub entry. Finally, we'll grant management the permission to view and administer revisions. node module access content @ ® H node module access content @ ® H
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Post a comment