I am customizing a site for a client.  Looking at the Admin/Users/Edit Permission Masks page, I can't make sense of what some of them do.  They are listed below with what I assume for some and no idea for others.

Reading:  This member level can access to read this section.

Commenting:  This member level can comment in this section.

Rating:  This member level can rate posts in this section.

Posting: This member level can add posts in this section.

Max Posts:  Limit on how many new posts can be added by this level of membership, with 0 being no limit.

Moderating:  Have no idea.

Uploading: This level of user can upload media files, ie image files, video, audio, etc. as it is included in the function of a module on a per module basis?

Parents:  Although it says at the top of the page, "Parent" means parent-level elements like blog, gallery, group, etc."  -  I have no idea what that means.  Could you explain and give an example, and is it available on all modules?

Categories: Don't know.  Does it somehow active the ability to break up a module's content into categories?  I see there are Areas and Categories in some, if not all modules, that seem to be a way of creating grouping levels for topics of information.  Don't know how those work and how this applies.

Moderator: Have no idea.  (I assume it means it has a moderator assigned to it? although I don't know what that would mean and how it functions in relationship to the moderator settings under User/Moderators).

Thanks

Configuring Usergroup Permission Masks

Below are explanations of each usergroup permission switch. Some of them haven't been fully implemented as of WWB 1.0.1.

• Reading: Allows or denies access to all content in the module. You can set global exceptions to this in variables.php / $core['sys']['allowed_pages_override'].
• Commenting: Allows or denies commenting on posts in the module. This is also used to control voting in Polls.
• Rating: Allows or denies rating of posts in the module.
• Posting: Allows or denies posting content into the module.
• Max. posts: Limits the maximum amount of posts a member can post into the module. (N/I)
• Moderated: Sets the status of the member's posts as "moderated", pending moderator review before going public. (N/I)
• Uploading: Allows or denies uploading content (images, audio, files, etc.) in the module. (N/I)
• Parents: Allows or denies creating "parents" in the module. (Parent in CMS hierarchy explained.)
• Categories: Allows or denies creating categories in the module.
• Moderator: Lets you assign usergroups as moderators on a per-module basis. (N/I)

If you want to quickly switch permissions on or off for an entire row (change all permissions for one module), or an entire column (change one permission for all modules), you can click (on) and double click (off) the row and column headers.

The next upcoming WWB build has a feature for cloning permission masks from one usergroup to another to make creation of new usergroups faster. Moderation features have been a long time coming, and will be included in one of the upcoming larger upgrades.

Parent and Category Control

Parent and category permission for usergroups let you control their ability to edit the different levels of content in your module.

In practice, this means for example that:

• In Articles module, you could create a usergroup "Editors" and let them create more shared categories for content, while regulars members can only post into them.
• In Groups module, only administrators can create categories, but members can create their own groups ("parents") in them.
• In Store, you could create a usergroup "Vendors" and let them create their own departments ("parent") into the store, turning it into a multi-vendor eMall.
• In Blogs module, members can create their own blogs ("parents") and categories in them for their blog posts. You could remove category permission if you wanted to simplify the structure into just blogs that contain posts. (A good idea for low-volume blogging sites.)

Permission Masks and Templating Script

Permission masks can also be used to control access of segments of HTML in the template files using templating script. For example, you could have the following anywhere in your template files or in custom HTML entered into the builder*:

Hello there!
<#IF:MASK_DENY:COMMENT#>Too bad you aren't allowed to comment.</#>
<#IF:MASK_ALLOW:COMMENT#>Too bad you aren't allowed to comment.</#>
<#IF:MASK_ALLOW:COMMENT&&IF:MASK_DENY:POST#>You can't post, but you can still comment!</#>
<#IF:MASK_ALLOW:COMMENT&&IF:MASK_ALLOW:POST#>Excellent — you can comment and also post!</#>
<#IF:MASK_ALLOW:COMMENT||IF:MASK_ALLOW:POST#>You can post either comments or posts.</#>

You can similarly use all the other masks in templating script, whether they are otherwise implemented or not. The masks are identified as READ, COMMENT, RATE, POST, MODERATED, UPLOAD, PARENT, CATEGORY, and MODERATOR respectively in the usage above.

You can combine conditions using "and" (&&) / "or" (||) logic. With &&, the content inside the templating script is only displayed if all conditions evaluate as true. With ||, it's displayed if any one of the conditions evaluates as true.

Currently you can only use && or || — not a mixture of both in one set of conditions — since use of parentheses isn't supported as of yet, and therefore such statements would conflict each other. There is no limit to the amount of conditions you can queue up. Templating script can't be nested like you would nest HTML tags inside each other.

* Be aware that TinyMCE editor breaks templating script as it mistakes it for strange HTML. If you use templating script for builder content, don't use the editor.