Start here

Home
About Klocwork
What's new
Fixed issues
Release notes
Installation

Reference

C/C++ checkers
Java checkers
C# checkers
MISRA C 2004 checkers
MISRA C++ 2008 checkers
MISRA C 2012 checkers
MISRA C 2012 checkers with Amendment 1
Commands
Metrics
Troubleshooting
Reference

Product components

C/C++ Integration build analysis
Java Integration build analysis
Desktop analysis
Refactoring
Klocwork Static Code Analysis
Klocwork Code Review
Structure101
Tuning
Custom checkers

Coding environments

Visual Studio
Eclipse for C/C++
Eclipse for Java
IntelliJ IDEA
Other

Administration

Project configuration
Build configuration
Administration
Analysis performance
Server performance
Security/permissions
Licensing
Klocwork Static Code Analysis Web API
Klocwork Code Review Web API

Community

View help online
Visit RogueWave.com
Klocwork Support
Rogue Wave Videos

Legal

Legal information

Configuring permission policies

You can use permission policies to control user access in Code Review. These policies can be enforced using the following:

  • Tags, which you apply to revisions
  • Paths, which point directly to the source file, an arbitrary path or path prefix that will match all paths below it. For example, if you add a permission policy for /my/path/, all files located in that directory will also share the same permission. A minimum of one tag must be specified with the path.

Important: You must be a Project root administrator to create and edit permission policies.

You can filter your list of permissions by user, tag or path using the Filter permissions field. For example, if you search for Joe Smith, all rules that apply to that user and any groups the user is in will be displayed.

The Access field allows you to allow or deny access to source files and tagged revisions. You can choose to allow or deny access for all users by choosing 'Allow all' or 'Deny all'. You can allow or deny access for specific users or groups by choosing either 'Allow' or 'Deny' and then adding user and group names in the Accounts field.

  • To apply the access rule to tagged revisions, add the desired tag names using the Specify Tag box.
  • To apply the access rule to paths, add a path prefix or absolute path using the Specify Path box along with at least one tag. All paths are applied as a prefix match. For example, /my/path will apply to all paths that start with the prefix '/my/path'.

If a tag and path is specified, the path prefix will only match paths in the specified tag(s). For example, deny all tags:myTag paths:/a/b will filter out revisions tagged with myTag that also have the path prefix /a/b. This overrides less specific permissions. In this case, deny all paths:/a/b will be overridden by allow all tags:myTag paths:/a/b because it is more specific.

Note: If you are using LDAP authentication, Code Review will add the canonic user name to the list of user names in a permission rule.

Collision resolution

If you have more than one permission policy attached to the same path or tag, this is considered a collision. The permission that is more specific has the priority. Collisions are handled as follows:

  • The base permission is allow all or deny all. All other permissions are more specific than the base and will override it. Untagged revisions will be displayed or hidden based on the base rule.
  • An account-specific rule takes precedence over an 'all users' rule.
    • E.g. allow 'userA' tags: 'tag1 ' takes precedence over deny all tags: 'tag1 ' and deny 'userA ' overrides allow all
  • A tag-only rule will take precedence over generic rules
    • E.g. allow 'userA' tags: 'tag1 ' takes precedence over deny 'userA ' and deny all
  • If a tag and a path is specified in the rule, that rule takes precedence over a rule with only a tag.
    • E.g. allow all tags: 'tag1' paths: '/my/path ' takes precedence over deny all tags: 'tag1 '
  • More specific paths will take precedence over less specific ones.
    • E.g. allow all tags: 'tag1' paths: '/my/path ' takes precedence over deny all tags: 'tag1' paths: '/ '

Examples

Allow access to all resources for everyone:

allow all

Deny access to all resources for everyone:

deny all

To deny all users access to anything under '/mypath' except for specific paths:

allow all
deny all tags: 'mytag' paths: '/mypath'
allow all tags: 'mytag' paths: '/mypath/a','/mypath/b'

Allow access for JSmith, otherwise deny access to all resources:

deny all
allow 'JSmith'

For JSmith, allow access to all resources except those tagged 'myTag'; deny access to all resources for all other users:

deny all
allow 'JSmith'
deny 'JSmith' tags:'myTag'

For JSmith, allow access to all resources except those tagged 'myTag' but allow access to '/my/path' in revision tagged with 'myTag'; deny access to all resources for all other users:

deny all
allow 'JSmith'
deny 'JSmith' tags:'myTag'
allow 'Jsmith' tags: 'myTag' paths: '/my/path'

For JSmith, all access to revisions tagged 'myTag' will be denied except for the specified paths:

allow all
deny 'JSmith' tags: 'myTag'
allow 'JSmith' tags: 'myTag' paths: '/my/path'

JSmith denied access to all but '/a' and is denied access to '/a' in revisions tagged 'myTag':

deny all
deny 'JSmith' tags: 'myTag' paths: '/a'
allow 'JSmith' tags: 'myTag', 'anotherTag' paths: '/a'