Permissions

This page contains a table for Users, Groups, and Administrator. The column headings, links above each table, and links in the Action column are the same for both tables. The same permissions can be granted (or not) to an individual user or a group. The table information is view-only. You use this page to set or modify permissions on other pages.

Functionality

You can enable permissions for multiple users or groups at once.
The Actions column lets you edit or clear permissions for the user or group in that row.
You can limit access to build information to the build owner and the administrator only. After this takes effect, only a user’s own builds are visible on the Builds page.
You can also:
Click a column heading to sort the information in that column.
Set the page refresh interval to keep your information current.
Set the number of records you want to see per page.

Column descriptions

The following column heading descriptions apply to either table.

Column Description

Column	Description
Name	Name of the user or group.
Access	Yes or No for permission to access the server.
Impersonate	Yes or No for permission to impersonate a different user or group to run eMake. Impersonate changes the user recorded by the Cluster Manager (CM) and that user’s permissions. This option does not affect OS user permissions. The simplest way to impersonate a user that can invoke eMake successfully is to meet the following conditions: The Cluster Manager must match your login user name to a user defined in Administration > Users The user defined on the Users page must have Impersonate permission The impersonated user must have Invoke permission The following example progresses through the steps to meet each condition. Example: The CM gets your user name from eMake, `mjones`. Then the Cluster Manager looks for a user defined in Administration > Users for a matching user. If unsuccessful, the Cluster Manager uses the `default ` user, whose Full Name is Anonymous. Next, the Cluster Manager looks in Administration > Permissions and matches the name to permissions. Only Impersonate and Invoke permissions impact the eMake client. The `default ` user has Invoke permission by default, but does not have Impersonate permission. Running eMake results in this error message: % emake --emake-cm bxb-step-002 --emake-impersonate-user=test ERROR EC3140: Couldn't start cluster build: NoImpersonateAccess: User 'Anonymous' is not allowed to impersonate other users If you create two users, mjones ` and `test, each with default permissions, the following error results when you run a build: % emake --emake-cm bxb-step-002 --emake-impersonate-user=test ERROR EC3140: Couldn't start cluster build: NoImpersonateAccess: User 'mjones' is not allowed to impersonate other users If you add `Impersonate permission` to the user `mjones ` and run a build, you get the following error: % emake --emake-cm bxb-step-002 --emake-impersonate-user=test ERROR EC3139: Couldn't start cluster build: NoBuildAccess: User 'test' does not have permission to run builds Adding `Invoke permission` to test ` allows the build to succeed. In the Builds tab, the User column contains ` test@Machine instead of ` mjones@Machine`.
Invoke	`Yes ` or `No ` for permission to invoke eMake.

Name

Name of the user or group.

Access

Yes or No for permission to access the server.

Impersonate

Yes or No for permission to impersonate a different user or group to run eMake. Impersonate changes the user recorded by the Cluster Manager (CM) and that user’s permissions. This option does not affect OS user permissions.

The simplest way to impersonate a user that can invoke eMake successfully is to meet the following conditions:

The Cluster Manager must match your login user name to a user defined in Administration > Users
The user defined on the Users page must have Impersonate permission
The impersonated user must have Invoke permission

The following example progresses through the steps to meet each condition.

Example: The CM gets your user name from eMake, mjones. Then the Cluster Manager looks for a user defined in Administration > Users for a matching user. If unsuccessful, the Cluster Manager uses the `default ` user, whose Full Name is Anonymous.

Next, the Cluster Manager looks in Administration > Permissions and matches the name to permissions. Only Impersonate and Invoke permissions impact the eMake client.

The `default ` user has Invoke permission by default, but does not have Impersonate permission. Running eMake results in this error message:

% emake --emake-cm bxb-step-002 --emake-impersonate-user=test
ERROR EC3140: Couldn't start cluster build:
NoImpersonateAccess: User 'Anonymous' is not allowed to impersonate other users

If you create two users, mjones ` and `test, each with default permissions, the following error results when you run a build:

% emake --emake-cm bxb-step-002 --emake-impersonate-user=test
ERROR EC3140: Couldn't start cluster build:
NoImpersonateAccess: User 'mjones' is not allowed to impersonate other users

If you add Impersonate permission to the user `mjones ` and run a build, you get the following error:

% emake --emake-cm bxb-step-002 --emake-impersonate-user=test
ERROR EC3139: Couldn't start cluster build:
NoBuildAccess: User 'test' does not have permission to run builds

Adding Invoke permission to test ` allows the build to succeed. In the Builds tab, the User column contains ` test@Machine instead of ` mjones@Machine`.

Invoke

`Yes ` or `No ` for permission to invoke eMake.

The next nine columns display None, Read, Modify, or `Full ` permission for the user or group.

Modify permission allows Read and Write privileges. Full permission allows Read, Write, and Delete privileges. Permission selections affect which information/options appear in the web interface.

Column	Description
Builds	Permission to read, write, or delete build entries
Agents	Permission to read, write, or delete agent entries
Build Classes	Permission to read, write, or delete build class entries
Messages	Permission to read, write, or delete message log entries
Administration	Permission to read, write, or delete entries in the Administration section (users, groups, and so on)
Reports	Permission to access reports
Resources	Permission to perform Resource Management activities (for example, build priorities or preemption policy)
User	None or Modify for permission to allow a user to change their own User Settings, Message Policies, filters, and Build Class notification
Break Points	Full or Modify Permission is available for users who must use breakpoint functionality Read lets users view breakpoint information in the CloudBees Build Acceleration web interface. Modify lets users interact with the breakpoint. Users can click Agent Command and Shell Command, which update the breakpoint by adding records to the database. Full lets users perform all breakpoint operations. Users can click Retry and Continue, which deletes the current breakpoint. If a breakpoint launches, and the user stops the build by killing the process, breakpoint information remains on the Build Details page, but the build is finished. Then there is a link to delete the breakpoint manually. See the Using Breakpoints help topic.
Actions	Edit User Permissions —Opens an edit page to change permissions for either a user or a group Delete User Permissions —Deletes all permissions for a single user or group

Column

Description

Builds

Permission to read, write, or delete build entries

Agents

Permission to read, write, or delete agent entries

Build Classes

Permission to read, write, or delete build class entries

Messages

Permission to read, write, or delete message log entries

Administration

Permission to read, write, or delete entries in the Administration section (users, groups, and so on)

Reports

Permission to access reports

Resources

Permission to perform Resource Management activities (for example, build priorities or preemption policy)

User

None or Modify for permission to allow a user to change their own User Settings, Message Policies, filters, and Build Class notification

Break Points

Full or Modify Permission is available for users who must use breakpoint functionality

Read lets users view breakpoint information in the CloudBees Build Acceleration web interface.

Modify lets users interact with the breakpoint. Users can click Agent Command and Shell Command, which update the breakpoint by adding records to the database.

Full lets users perform all breakpoint operations. Users can click Retry and Continue, which deletes the current breakpoint. If a breakpoint launches, and the user stops the build by killing the process, breakpoint information remains on the Build Details page, but the build is finished. Then there is a link to delete the breakpoint manually.

See the Using Breakpoints help topic.

Actions

Edit User Permissions —Opens an edit page to change permissions for either a user or a group

Delete User Permissions —Deletes all permissions for a single user or group