/* Displays the information stored in the `p4 protect` command. */ function Protections(data) { Object.defineProperties(this, { /* Each item in the protections array is a line in the protections table, and is split into five columns. 1. Access level or mode. One of the access levels list, read, open, write, admin, super, review; or one of the rights =read, =open, =write, and =branch, 2. Either `user` or `group`, to indicate what's identified by this entry. 3. The group name or user name. To grant permission to all users, use a wildcard with just an asterix symbol. 4. The IP address of the client host. 5. The depot file path, which can contain wildcards. To exclude this mapping from the permission set, use a dash `-` as the first character of this value. IPv6 addresses and IPv4 addresses are also supported. You can use the * wildcard to refer to all IP addresses, but only when you are not using CIDR notation. If you use the * wildcard with an IPv6 address, you must enclose the entire IPv6 address in square brackets. For example, [2001:db8:1:2:*] is equivalent to [2001:db8:1:2::]/64. Best practice is to use CIDR notation, surround IPv6 addresses with brackets, and to avoid the * wildcard. How the system forms host addresses depends on the setting of the dm.proxy.protects variable. By default, this variable is set to 1. This means that if the client host uses some intermediary (proxy, broker, replica) to access the server, the proxy- prefix is prepended to the client host address to indicate that the connection is not direct. If you specify proxy-* for the Host field, that will affect all connections made via proxies, brokers, and replicas. A value like proxy-10.0.0.5 identifies a client machine with an IP address of 10.0.0.5 that is connected to the server through an intermediary. Setting the dm.proxy.protects variable to 0, removes the proxy- prefix and allows you to write a single set of protection entries that apply both to directly-connected clients as well as to those that connect via an intermediary. This is more convenient but less secure if it matters that a connection is made using an intermediary. If you use this setting, all intermediaries must be at release 2012.1 or higher. */ "protections": { value: data ? data.protections : undefined, enumerable: true, writable: true } }); } module.exports = Protections;
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#1 | 19553 | swellard | Move and rename clients | ||
//guest/perforce_software/helix-web-services/main/source/clients/2016.1.0/javascript/lib/models/protections.js | |||||
#2 | 19169 | tjuricek | JavaScript Client SDK jobs CRUD test, with supprt for "additionalProperties" in the swagger definition. | ||
#1 | 19053 | tjuricek |
Rebuild JavaScript Client SDK. The JavaScript client now is a "typed" approach that tends to be similar in approach to the other clients, based on the swagger definition for the platform version. Importantly, client SDK tests are individual scripts (that run under node) that are actually controlled via TestNG. This approach now lets us use a consistent test reporting format so we can at least collect reports from each of the jobs. The documentation is still in progress, that I want to validate as the tests are generated. |