What’s New in AccuRev 7.1

Highlights of the new developments in AccuRev 7.1 are presented here.

In this topic:

Enhanced Filtering in the History Browser

AccuRev 7.1 offers enhanced filtering capabilities in the History Browser to enable you to hone in on the transaction information that is of interest to you. In previous releases of AccuRev, the History Browser’s table of transactions could be filtered to display only the transactions performed by a specific user. AccuRev 7.1 expands upon that, providing filtering by users, groups, and actions.

In the Users filter, you can now elect either to see transactions by all users or to filter by users or groups.

AccuRev groups are displayed at the bottom of the dropdown menu. You can select any one of the groups in order to see what transactions were executed by members of that group. If you choose “Select Users…” instead, a dialog will appear and allow you to divide the set of AccuRev users into an Included list (the users whose transactions will be displayed in the History Browser) and an Excluded list (the users whose transactions will be hidden from view). Left- and right-arrows move selected users from one table to the other, and the Swap button  performs a quick exchange of the two tables’ contents.

The new Actions filter in the History Browser allows you to select what types of actions you want to see listed in the transactions table. Again, you use the arrow buttons to divide the set of action types into an Included list and an Excluded list and then click on the OK button.

The tooltips for the Users and Actions filters identify how the history display is currently being filtered. For example:

As shown in the examples above, the Users and Actions filters can be used in conjunction to focus on select actions committed by a specific set of users.

A new Clear button resets all the filters located to the left of the button back to their default state:

Note: The Active Transactions default group in the Stream Browser no longer contains a Users filter. Instead, you can filter active transactions by user via the advanced filters now available in the Active Transactions tab.

Back to top

Admin Command Permissions GUI

A new graphical user interface has been implemented to enable the AccuRev administrator to configure which users are allowed to execute a variety of administrative level commands. Previously, the way to do this was to write perl script in the server_admin_trig.bat or server_admin_trig.pl files installed in the <ac-install>/storage/site_slice/triggers directory.

Here is a look at the new GUI:

This configuration page is accessible from the “Admin” menu underneath the “Security” option. The “Global Default” Condition allows you to configure admin command permissions for the entire site. Command permissions can apply to an individual user or to a specific group of users. You can also apply permissions broadly to the two built-in groups:

• anyuser — All users without a password

• authuser — All users with a password

In the case that permissions have been configured for both a user directly and a group that the user is a member of, the permission setting closest to the user is the one that applies. For example, if a user is a member of the “qa” group and the “qa” group is denied access to the “chstream” command, but the user is specifically configured to be allowed permission to the “chstream” command, the user’s own permission is the one that applies.

Configuring a Superuser

In order to set or remove admin command permissions, you must either be a superuser or have been granted explicit “allow” permission for the “setcmdacl” and “rmcmdacl” commands. To designate a user as the superuser, the AccuRev administrator must use the maintain utility:

maintain su -a <username>

Changing Command Permissions

To edit command permissions, you must either select one of the existing conditions that you want to edit or add a new condition. The conditions are either the site-wide “Global Default” command permissions or command permissions set on a specific stream. Only commands that apply to a stream or stream hierarchy can be configured at the stream level. Examples of commands that are configurable by stream are: setting stream properties, mkstream, and chstream.

Either highlight the condition you want to edit and click the “Change Command Permissions” button, double-click on the condition, or right-click on the condition and choose the “Change Command Permissions” context menu option. The following dialog will appear:

Now you need to add the user or group whose command permissions you want to configure. Command permissions are configured for one single user or one specific group of users at a time. This is similar to how Windows file permissions can be configured. You can add multiple users to the “Applies To” section of the dialog, but the “Command Permissions” that you configure apply only to the currently highlighted user or group:

 

Notice that the title of the “Command Permissions” section identifies the user or group whose permissions are being configured.

If you add testuser1 to the Applies To section, you can see that the command permissions for “testuser1” can also be configured now. Once you configure permissions for the desired set of users and groups, click OK to save your changes.

Stream-Aware Command Permissions

For commands that apply to a stream or stream hierarchy, you can add a new condition for that stream and configure command permissions that you want to apply to it only. You can also choose to make your command permission setting inheritable so that it applies to the entire stream hierarchy below the specified stream. For example, suppose you want to allow users to change the streams in the "development" stream hierarchy, but you don’t want anyone to change streams above that level. To accomplish this, you could deny access to chstream in the global default, but set an explicit inheritable "allow" permission for the chstream command on the “development” stream:

 

Removing Command Permissions

To remove a condition entirely (except for the Global Default Condition), highlight the condition and click the “Remove Command Permissions” button. To remove command permissions for a specific user or group from a condition, highlight that condition and select “Change Command Permissions”. In the dialog that pops up, remove the users and groups that you no longer want permissions to be set for.

By default, if no permission is set for a user or any group he is a member of or the built-in group that he is a member of, the user is implicitly granted "allow" permission for that command.

Back to top

Push Notifications

In Release 7.1, the AccuRev server generates push notifications for all write operation events. These notifications are published through the Mosquitto MQTT Broker, which was introduced in AccuRev 6.2 for use with Gated Streams. The notifications are configurable at the server side, consumed by the GUI, and available to users at the client level via the CLI.

Server

A new setting called NOTIFICATION_LEVEL in the acserver.cnf file configures the type of notifications that are published.

All notifications are classified into the following four categories:

• Streams (e.g., keep, promote, chstream)

• AccuWork (e.g., create/edit an issue, cpkadd)

• Depot (e.g., mkdepot, mktrig)

• Site (e.g., mkuser, chgroup)

To specify which notifications get published, add the values for each desired category together. Streams and AccuWork notifications would be 3, for example; all notifications would be 15. To turn the feature off, set the notification level to 0.

The default notification level is 1 -- stream-type notifications only.

GUI

The views that a user has open in the GUI can become out-of-date as other AccuRev users execute operations. In 7.1, the GUI uses the server-generated stream notifications to display “notification badges,” which give the user a hint that activity has occurred in the stream(s) they are viewing.

The GUI displays notification badges in the tab header of the following types of views:

• Stream Browser

• History (depot, stream/workspace, transactions)

• File Browser

In the screenshot below, the badge indicates that two new transactions have occurred in this Stream (Workspace) History view.

Badge notification counts increment for each new applicable transaction that has occurred since the view was generated or refreshed. Refreshing the view clears the badge (since the view then includes the latest transactions).

Notification badges are configured via a preference setting. There is one global setting for all types of views:

CLI

The new trace-event CLI command listens for the server-generated notification events and can print them to the screen, output them to a log file, or pass the values to a script to take some user-defined action.

trace-event has arguments to filter notifications based on category or notification kind, by depot, stream, or user. If you specify no arguments, trace-event listens and prints all push notifications generated by the server.

# accurev trace-event

Trace Event: Connected to server myserver:1883

Trace Event: Subscribing to ‘accurev/info/notifications/+’

Refer to the CLI User’s Guide for additional details on the command arguments and examples.

Site administrators can control access to the trace-eventcommand through the newAdmin Command Permissions GUI or through the traditional server_admin_trig trigger. Users without access to the trace-event command will see the error message “You are not authorized to perform this operation.”

Back to top