test(grant): Use ID to validate version check (#4274)

* test(grant): Use ID to validate version check

* Update docs from id to ids

* Remove 'id' in 0.16.0

internal/cmd/commands/rolescmd/funcs.go

@@ -285,7 +285,7 @@ func extraFlagsHandlingFuncImpl(c *Command, _ *base.FlagSets, opts *[]roles.Opti
 			case parsed.Id() == "":
 				// Nothing
 			case version.SupportsFeature(version.Binary, version.SupportIdInGrants):
-				c.UI.Warn(fmt.Sprintf("Grant %q uses the %q field, which is deprecated and will not be allowed in version 0.15.0+. Please use %q instead.", grant, "id", "ids"))
+				c.UI.Warn(fmt.Sprintf("Grant %q uses the %q field, which is deprecated and will not be allowed in version 0.16.0+. Please use %q instead.", grant, "id", "ids"))
 			default:
 				c.UI.Error(fmt.Sprintf("Grant %q uses the %q field which is no longer supported. Please use %q instead.", grant, "id", "ids"))
 				return false

internal/daemon/controller/handlers/roles/role_service_test.go

@@ -2184,9 +2184,9 @@ func TestAddGrants(t *testing.T) {
 		},
 		{
 			name:     "Check id field deprecation",
-			existing: []string{"ids=u_fooaA1;actions=read"},
-			add:      []string{"ids=*;type=*;actions=delete"},
-			result:   []string{"ids=u_fooaA1;actions=read", "ids=*;type=*;actions=delete"},
+			existing: []string{"id=u_fooaA1;actions=read"},
+			add:      []string{"id=*;type=*;actions=delete"},
+			result:   []string{"id=u_fooaA1;actions=read", "id=*;type=*;actions=delete"},
 			wantErr: func() bool {
 				return !version.SupportsFeature(version.Binary, version.SupportIdInGrants)
 			}(),
@@ -2338,9 +2338,9 @@ func TestSetGrants(t *testing.T) {
 		},
 		{
 			name:     "Check id field deprecation",
-			existing: []string{"ids=u_fooaA1;actions=read"},
-			set:      []string{"ids=*;type=*;actions=delete"},
-			result:   []string{"ids=*;type=*;actions=delete"},
+			existing: []string{"id=u_fooaA1;actions=read"},
+			set:      []string{"id=*;type=*;actions=delete"},
+			result:   []string{"id=*;type=*;actions=delete"},
 			wantErr: func() bool {
 				return !version.SupportsFeature(version.Binary, version.SupportIdInGrants)
 			}(),

internal/tests/cluster/recursive_anon_listing_test.go

@@ -32,7 +32,7 @@ func TestListAnonymousRecursing(t *testing.T) {
 	require.NoError(err)
 	customRole, err = rolesClient.AddPrincipals(tc.Context(), customRole.Item.Id, customRole.Item.Version, []string{"u_anon"})
 	require.NoError(err)
-	_, err = rolesClient.AddGrants(tc.Context(), customRole.Item.Id, customRole.Item.Version, []string{"id=*;type=auth-method;actions=list,authenticate"})
+	_, err = rolesClient.AddGrants(tc.Context(), customRole.Item.Id, customRole.Item.Version, []string{"ids=*;type=auth-method;actions=list,authenticate"})
 	require.NoError(err)
 
 	// Create an auth method in org scope for the test

version/feature_manager.go

@@ -75,10 +75,10 @@ func init() {
 		Constraints: mustNewConstraints(">= 0.13.0"),
 	}
 
-	// Warn until 0.15 about using the now-deprecated id field in grants; after
+	// Warn until 0.16 about using the now-deprecated id field in grants; after
 	// that disallow it
 	featureMap[SupportIdInGrants] = MetadataConstraint{
-		Constraints: mustNewConstraints("< 0.15.0"),
+		Constraints: mustNewConstraints("< 0.16.0"),
 	}
 
 	// PluginDelete supports calling DeleteObjects on the Storage Plugin

website/content/docs/common-workflows/manage-roles.mdx

@@ -139,7 +139,7 @@ In this example we give a role read and list permissions to all resources.
 <Tab heading="CLI">
 
 ```bash
-boundary roles add-grants -id $role_id -grant 'id=*;type=*;actions=no-op,list'
+boundary roles add-grants -id $role_id -grant 'ids=*;type=*;actions=no-op,list'
 
 Role information:
   Created Time:        Fri, 09 Oct 2020 14:45:47 PDT

website/content/docs/concepts/iam.mdx

@@ -55,7 +55,7 @@ There are 3 steps to adding new users to Boundary using the password auth method
 
 ### Configure users - OIDC/LDAP
 With the [OIDC](/boundary/tutorials/identity-management/oidc-auth) and LDAP auth methods, Boundary uses data from the identity provider to automatically generate accounts and users in the same scope
-as the auth method. The accounts and users are only created once the user authenticates to Boundary for the first time. 
+as the auth method. The accounts and users are only created once the user authenticates to Boundary for the first time.
 The same applies to OIDC/LDAP [managed groups](/boundary/tutorials/identity-management/oidc-idp-groups).
 
 ### Grant permissions
@@ -75,14 +75,14 @@ Projects.
 2. Each role needs to have the user/group added as a principal
 3. Each role needs to have the grants of
 
-   - `id=*;type=*;actions=*`
+   - `ids=*;type=*;actions=*`
 
 ### Boundary viewer
 1. **Each** of the 7 scopes requires a role (ex. “viewer”)
 2. Each role needs to have the user/group added as a principal
 3. Each role needs to have the grants of
 
-   - `id=*;type=*;actions=read,list`
+   - `ids=*;type=*;actions=read,list`
 
 ### Org_A admin
 1. The following scopes **each** require a role (ex. “admin”)
@@ -92,22 +92,22 @@ Projects.
 2. Each role needs to have the user/group added as a principal
 3. Each role needs to have the grants of
 
-   - `id=*;type=*;actions=*`
+   - `ids=*;type=*;actions=*`
 
 ### Project_1 admin
 1. Project_1 requires a role (ex. “admin”)
 2. The role needs to have the user/group added as a principal
 3. The role needs to have the grants of
 
-   - `id=*;type=*;actions=*`
+   - `ids=*;type=*;actions=*`
 
 ### Project_1 target access
 1. Project_1 requires a role (ex. “target_access”)
 2. The role needs to have the user/group added as a principal
 3. The role needs to have the grants of
 
-   - `id=*;type=target;actions=list,read,authorize-session`
-   - `id=*;type=session;actions=read:self,cancel:self,list`
+   - `ids=*;type=target;actions=list,read,authorize-session`
+   - `ids=*;type=session;actions=read:self,cancel:self,list`
 
 <Tip>
 You can use the same roles across “Boundary Admin”, “Org_A Admin”, and “Project_1 Admin” since the scopes and grants are the same. The only difference is

website/content/docs/concepts/security/permissions/assignable-permissions.mdx

@@ -99,7 +99,7 @@ The resulting behavior is as follows: `output_fields` references the field names
 of the JSON object response, composes just like other parts of the RBAC model,
 and are action-specific. That is, a grant like:
 
-`id=*;type=auth-methods;actions=list,no-op;output_fields=scope_id,name,description`
+`ids=*;type=auth-methods;actions=list,no-op;output_fields=scope_id,name,description`
 
 will, if all by itself, result in those three identified output fields applying
 to `list` (and `no-op`) actions for all auth methods in the scope. Thus when
@@ -109,7 +109,7 @@ use defaults.
 
 A grant like:
 
-`id=*;type=auth-methods;output_fields=id`
+`ids=*;type=auth-methods;output_fields=id`
 
 will, if all by itself, result in _any_ action against auth methods in the scope
 having only `id` returned.
@@ -134,4 +134,4 @@ composition, is equivalent to using Boundary's default; however the moment that
 grants start specifying output fields, it is composed from an empty set and thus
 nothing is contained unless explicitly specified. (An actual empty set is not
 currently supported, as we don't perform validation on the values given.
-However, this means setting `output_fields=none` is functionally equivalent!)
+However, this means setting `output_fields=none` is functionally equivalent!)

website/content/docs/concepts/security/permissions/index.mdx

@@ -33,7 +33,7 @@ and mapped to users via roles.
 
 A grant string has a form similar to:
 
-`id=<id>;type=<type>;actions=<action list>;output_fields=<fields list>`
+`ids=<id>;type=<type>;actions=<action list>;output_fields=<fields list>`
 
 Each grant string is a mapping that describes a resource or set of resources and
 the permissions that should be granted on them.
@@ -86,4 +86,4 @@ scope ID and one or more of the following are true:
   role
 
 Roles are composable; a user's final set of grants will be composed of grants
-that originate from all matching roles.
+that originate from all matching roles.

website/content/docs/concepts/security/permissions/permission-grant-formats.mdx

@@ -22,7 +22,7 @@ _only_ `output_fields`.
 This is the simplest form: for a given specific resource, allow these actions.
 Example:
 
-`id=hsst_1234567890;actions=read,update`
+`ids=hsst_1234567890;actions=read,update`
 
 This grants `read` and `update` actions to that single resource. It is invalid
 to specify `create` or `list` as actions in this format, as this format
@@ -63,7 +63,7 @@ the pinned format shown below.
 This form "pins" actions to a non-top-level type within a specific ID. It's
 easiest to explain with an example:
 
-`id=hcst_1234567890;type=host-set;actions=create,read,update`
+`ids=hcst_1234567890;type=host-set;actions=create,read,update`
 
 In this example, the user is able to create, read, or update host sets within
 the scope, but _only the host sets belonging to host catalog hcst_1234567890_.
@@ -79,13 +79,13 @@ Various wildcard possibilities are allowed:
 When just the ID is `*`, it matches all IDs of the given type. This can be used
 with both top-level resource types and not. Example:
 
-`id=*;type=host-set;actions=create,read,update,set-hosts`
+`ids=*;type=host-set;actions=create,read,update,set-hosts`
 
 ### Wildcard type
 
 For non-top-level resources with pinned IDs, the `type` can be a wildcard:
 
-`id=hcst_1234567890;type=*;actions=create,read,update`
+`ids=hcst_1234567890;type=*;actions=create,read,update`
 
 This would allow `create`, `read`, and `update` actions for all types of
 subordinate resources (in this case host sets and hosts) underneath the host
@@ -97,13 +97,13 @@ If ID and type are both a wildcard, the grant is essentially a catch-all that
 will match any resource of any type within the scope and allow the given
 actions.
 
-`id=*;type=*;actions=read,list`
+`ids=*;type=*;actions=read,list`
 
 ### Wildcard ID, type, and actions
 
 Finally, ID, type, and actions can all be wildcards:
 
-`id=*;type=*;actions=*`
+`ids=*;type=*;actions=*`
 
 Such a grant is essentially a full administrator grant for a scope.
 
@@ -114,7 +114,7 @@ substitute the given value into the ID field of the grant string:
 
 - `{{.Account.Id}}`: The substituted value is the account ID associated with the
   token used to perform the action. As an example,
-  `id={{.Account.Id}};actions=read,change-password"` is one of Boundary's
+  `ids={{.Account.Id}};actions=read,change-password"` is one of Boundary's
   default grants to allow users that have authenticated with the Password auth
   method to change their own password.
   - **NOTE**: Prior to Boundary 0.11.1, `{{account.id}}` must be used instead.

website/content/docs/install-boundary/no-gen-resources.mdx

@@ -321,9 +321,9 @@ $ boundary roles create -name 'global_anon_listing' \
 
 $ boundary roles add-grants -id <global_anon_listing_id> \
   -recovery-config /tmp/recovery.hcl \
-  -grant 'id=*;type=auth-method;actions=list,authenticate' \
-  -grant 'id=*;type=scope;actions=list,no-op' \
-  -grant 'id={{.Account.Id}};actions=read,change-password'
+  -grant 'ids=*;type=auth-method;actions=list,authenticate' \
+  -grant 'ids=*;type=scope;actions=list,no-op' \
+  -grant 'ids={{.Account.Id}};actions=read,change-password'
 
 $ boundary roles add-principals -id <global_anon_listing_id> \
   -recovery-config /tmp/recovery.hcl \
@@ -365,9 +365,9 @@ $ boundary roles create -name 'org_anon_listing' \
 
 $ boundary roles add-grants -id <org_anon_listing_id> \
   -recovery-config /tmp/recovery.hcl \
-  -grant 'id=*;type=auth-method;actions=list,authenticate' \
+  -grant 'ids=*;type=auth-method;actions=list,authenticate' \
   -grant 'type=scope;actions=list' \
-  -grant 'id={{.Account.Id}};actions=read,change-password'
+  -grant 'ids={{.Account.Id}};actions=read,change-password'
 
 $ boundary roles add-principals -id <org_anon_listing_id> \
   -recovery-config /tmp/recovery.hcl \
@@ -410,7 +410,7 @@ $ boundary roles create -name 'org_admin' \
 
 $ boundary roles add-grants -id <org_admin_id> \
   -recovery-config /tmp/recovery.hcl \
-  -grant 'id=*;type=*;actions=*'
+  -grant 'ids=*;type=*;actions=*'
 
 $ boundary roles add-principals -id <org_admin_id> \
   -recovery-config /tmp/recovery.hcl \
@@ -452,7 +452,7 @@ $ boundary roles create -name 'project_admin' \
 
 $ boundary roles add-grants -id <project_admin_id> \
   -recovery-config /tmp/recovery.hcl \
-  -grant 'id=*;type=*;actions=*'
+  -grant 'ids=*;type=*;actions=*'
 
 $ boundary roles add-principals -id <project_admin_id> \
   -recovery-config /tmp/recovery.hcl \